クラウドインフラ構築記

現在AWSの構築支援に携わっております。今注視しているのは、GKE、BigQuery、Google Dataflowなどサービスを展開しているGoolge Cloud Platformです。

SRE NEXT Day2

基調講演

デザイン、物のデザインから、中身がよくわからないものをどう目的するインタラクションデザイン、ユーザの体験をどうするかフォーカスに入ってきた

デザイン、理解しないと、本質的なものを作れない、SREでも仕様を理解しないと作り上げられないものに当てはまりそう

仮説を作って、確かめることをしない 基盤検討する場合もPoCなり、裏どりとかするプロセスにも当てはまりそう

サンプリングは統計学である: 数理的根拠に基づき、オブザーバビリティのコストと精度を両立する

母集団が偏りがあるのか均一性があるのか、どれくらいの誤差が発生するのか、ブレの範囲に95%入っているサンプリングの精度につながる サンプリング、長い間のウィンドウにすることで少ないサンプリングでも誤差少なくなる

しぶいSRE: サーバから見えない障害にどう向き合うか。ラストワンマイルのデバッグ実践

サーバーインフラリソースに異常なくても、外部要因でクライアントでエラーになっていることがある。クライアントの環境に依存するケースにもなっているので原因特定が難しくなる

サーバーインフラリソースに異常なくても、外部要因でクライアントでエラーになっていることがある。クライアントの環境に依存するケースにもなっているので原因特定が難しく

End-to-Endで考える信頼性 — LINEアプリにおけるクライアント開発×SRE連携の実践

コンテンツキャッシュ切れて、サイトアクセスできない場合もキャッシュさせる 表示するキャッシュがない場合、ローカルに最低限のコンテンツを持つ fallbackコンテンツを表示する

Slido でQA取り上げてくれた内容になりますが、外部リソース取るケースもサーキットブレイカーで外部リソース取る際長く待たせるのではなく、トルツメするなりして応答レスポンス劣化を防ぐ工夫も。主要導線でなければトルツメされても問題ないケースもある

月間400万ジョブを支えるGitHub Actions self-hosted runnerの信頼性

大規模で運用しているSelf Hosted Runnerのジョブ、API rate limitとか、node poolのIO性能違うことでジョブ時間がばらけてしまった。node pool、キャッシュ持っていないケースもあると変更ありそう

コメントは受け付けていません。