HERPにおけるSRE実践のこれまで_2023年版
これは何?
SREチームによる、これまでのHERPにおけるSRE実践の歴史に関するメモ
大きな方針
HERP Hireをはじめとしたサービスのスケールに伴い、ちゃんとSREに取り組んでいこうという話になった
Books For Site Reliability Engineering を参考にいくつかの重要サービスに絞ってまずは組織で方法論を実践できるようになることを最優先
特に Dickerson pyramid を指針に据え、下から順番に強化していくことにした
取り組み一覧
監視改善
2017
kopsを使っていたのでlog収集がcloudwatch logs
datadogへ
2018
sentry
2019
eks
istioとenvoy
durationのmetricsとかerror rateが取れる
Argo CD を導入した
nix plugin を作って kustomize や helm のアプリケーション(当時は Argo CD 本体が未対応だった)のデプロイをする
2021
上のSREの枠組みでやっていきましょうって意思決定をした
Datadog RUM 導入と Sentry 廃止
2022
SLI / SLOの導入など
SRE実践の基本ツールである、SLI / SLOを基幹コンポーネントで扱えるようにすることを目標にSREと開発者でダッシュボード改善会を実施した
ダッシュボード改善会とは
開発者にコンポーネントの監視を中心とした運用業務を自力で担ってもらえるようにするために、コンポーネントのダッシュボードを一緒に作っていく会
コンポーネントが担っている機能は何か、その機能はどのようなエンドポイントなどによって実現されているのか、そのエンドポイントに求められる品質にはどのようなものがあるのか、といった内容をSREがヒアリングすることで言語化してもらい、その内容を元にダッシュボードを構築した
コンポーネントについて何が重要かが言語化できているので、それを元に監視ルールやSLIの設計を実施した
ビジネスメンバーを含めた全体にSLI / SLOについて説明を実施し、週単位で設定したSLOが達成できていない場合には新規機能のリリースを凍結し、専用の調査チームを組成し改善に取り組むことに理解を得た
導入後
ダッシュボード改善会に参加してくれたメンバーからコンポーネントの運用業務に自主的に取り組んでくれるメンバーが誕生した
これまでに数回リリースを凍結し調査改善を実施した
その中には放置していたら重大な問題を引き起こしていたであろう問題を小さいうちに解消できたというケースもあった
SLIやSLO自体を継続的に更新していく部分についてはまだまだこれから
他のサービスへの横展開についてもこれから
2023
onix (ジョブミル等の新規事業用の環境)を整備
HERPでの採用技術への特殊対応
gRPC
GHCのGCにかかっている時間
障害対応フロー・体制の整備
2021
opsわいわい
アプリケーションエンジニアがダッシュボードとかをみる習慣をつけるため
障害対応ローテ
ポストモーテム文化の普及
テストとリリース作業
AWS環境分離
負荷試験
キャパシティプランニング
spot instanceとか?
ワークロード特性に応じたNodeGroupの整理
開発支援
codex
CI / CD改善
プロダクト改善
apm導入
Profiler導入
今後の課題とこれからやっていきたいこと
SLO のカバー範囲をさらに広げる
デプロイパイプラインの整備
アプリケーションのデプロイ時のトイルを減らしたい
新規事業の拡大にあわせて基盤を整えていく
APM ベースの metrics に切り替える
istioとenvoy を使った仕組みで運用を続けているが限界