🐈

SRE を立ち上げた4ヶ月後の世界

2023/12/04に公開

DevOps

SRE

tech

この記事は、Magic Moment Advent Calendar 2023 4 日目の記事です。

こんにちは! Magic Moment で Senior Engineering Manager 兼 SRE Engineering Manager をやっている木村 (@ryurock) です。

Magic Moment アドベントカレンダー 4 日目では、2023年9月に SRE チームを立ち上げた 4 ヶ月後の世界。
というテーマでアドカレやっていきたいと思っています。( ｰ`дｰ´)ｷﾘｯ

SRE チームの立ち上げの経緯

遡る事、2023年7月頃に弊社が提供しているサービス Magic Moment Playbook のコアデータが立て続けに更新できない障害が相次ぎました。

Sales Operation を行う上で、大切なデータが頻繁に反映されないこの由々しき事態はユーザー様にとって不便な状況を強いてしまっている状態になってしまいました。

2023/08/01 事態を重く見て緊急対策チームを発足して、原因を対応して解決。
しかし中々原因が特定できず、解決に時間を要しました。

その後行ったポストモーテムでは大反省会の嵐でした (一部抜粋)

カスケード障害になるケースをアーキテクチャで防いでいなかった
データ増加に伴うデータレイヤーの不整備
システムパフォーマンスを定点チェックをおこなっておらず、システムの状態変化に気づけなかった
Toil を放置した結果、複数の要因が絡み合い本当の原因がわかりづらかった
etc.............

元々、Magic Moment では、SRE 活動はしていたのですが、組織拡大フェーズにおける中で SRE 活動の優先順位が上がらず後手後手の状態になっていました

アプリケーションや組織拡大に伴い、SRE 活動の整備が追いついていなかった
- SRE 活動が兼任だと、優先順位が下がってしまう
運用・保守の部分がおざなりになっていた
- 成長フェーズなのでしょうがない。の積み重ねが Toil やノイズを膨らませて、原因特定に大きく時間がかかった
システムパフォーマンスの定点チェックを行っておらず、システムの状態変化に気づけなかった
- Datadog の導入で解決しようとしていたが間に合わなかった
etc.............

このような反省を元に、SRE チームが発足しました。

SRE を組織として、いつから本格稼働させるのか？

DevOps は、古来 Dev と Ops の対立構造をどうにかしたい。
という流れからきていて、今は Cloud Infrastructure が当たり前の時代。

できれば Dev と Ops で分けるようなチーム構造ではなく、Infra と Application 両方、自分のチームの持ち物は自分たちで解決をしたいから SRE をチームとして、積極的に持ちたくない。

この気持ちはよくわかりますし、自分もできうるならば、そうしたほうが良い。と思っています。

SRE チームという Ops がそもそもいなければ、Dev と Ops の対立構造にならないので。
しかし、組織が成長していくにしたがって、安定性の責任が徐々に加速度的に上がってきます。

開発チーム(Dev)は、機能開発に必死で、ついつい Ops を後回しにしてしまう。この成長フェーズの筋肉痛とも言える痛みは、Magic Moment 以外の組織でもよくある問題だと思っています。

また、シードフェーズ初期という状況だと、半年後、どうやって生き残るか？と今生きるのに必死です。

限られた予算の中で、SRE にコストを割くのが、難しい。これもまた現実かな？と思っています。

そう考えると、いつから守備に厚みをもたせるか？は非常に悩ましい問題ですが、今回は大きなペインからの学びで SRE チームが立ち上がりました。

SRE チームを立ち上げ後にやったこと

大きく分けると下記になります。

SRE プラクティスをどれからやって、どのように SRE 文化を醸造していくか？の SRE 戦略とトリアージ
可視化文脈の Alert の整理と SLI の指標の整理と Dashboard の作成
Micro Service 間で疎結合になって全体の処理を把握するのが難しくなってきたので、 Datadog APM と分散トレーシングを導入して、チーム間のコラボレーションの導線をツールで作る

それぞれでどんな意図があってどんな効果があったか？に行きたいと思います。

SRE プラクティスをどれからやって、どのように SRE 文化を醸造していくか？の SRE 戦略とトリアージ

SRE 経験の少ない開発者が SRE 活動するときによく陥る罠が「SRE の How 」にフォーカスしてしまうことです。

この SRE の How にフォーカスして、一貫性を持たない指標やルールを運用しだすと、更に何を見れば良いのか？の複雑度が増していきます。

この良かれと思ってやる善意がやがて「地獄への道は善意で舗装されている」を助長させます。

なので、まず「How」よりも

Why なぜその SRE プラクティスをやる必要があるのか?
What どの SRE プラクティスをやると現状のボトルネックにアプローチができるのか？
When いつまでに What をやるのか？

の戦略とトリアージを行いました。

可視化文脈の Alert の整理と SLI の指標の整理と Dashboard の作成

まず SRE 活動をする上で重要なのが、「だと思っている (意見)」と Fact (事実) を切り分ける事、すなわち計測です。
計測指標 (SLI) をサービス横断で統一的な指標を用いる事で初めて意見 (Opinion) と事実 (Fact) を全体で見極められる事ができます。

そこで危険性の事実 (Fact) をまずは、System Alert を徹底的に整備しました。
SRE チームを 2023 年 9月に立ち上げた当初、System Alert はわずか 13 個しかありませんでしたが、2023 年 11 月時点で 242 個迄増やしました。

全て Terraform で管理している状態です。

次に全ての Micro Service の現実を同じ指標でみれるように Datadog Dashboard の整理をしました。

これは

エラーノイズの事実
Latency の事実

この2つを意見(Opinion)から事実(Fact)に変換させるためです。

この2つの事実に基づいて、各チームに配置している Embedded SRE と共に定期リリースの翌日に事実の状態変化が起こっていないか？を毎週チェックして事実関係を組織全体で向き合える状態にしました。

Magic Moment は Micro Service Architecture を採用していますが、Micro Service のデメリットである、全体把握の難易度が上がります。
また、リポジトリ戦略では、Polyrepo を採用しているので、チーム間のサイロ化が発生しやすいです。

事実を元に、Metrics を通じて共に知識を共有する場を醸造して、チーム間のコラボレーションのコミュニケーション経路を確保する。

これが、SRE の可視化でできる本当に大切な事だと思っています。

Metrics や SLI を策定して「Alert が鳴りました。対応お願いします」だけでは、本当の問題は解決できません。
また大概の場合、障害は単一的な問題によって引き起こされるケースはほとんどなく、複合的な要因によって引き起こされます。

ここでもやはり、まず「How」よりも「Why,What」の浸透が重要です。

Micro Service 間で疎結合になって全体の処理を把握するのが難しくなってきたので、 Datadog APM を導入して、チーム間のコラボレーションの導線をツールで作る

事実に向き合う事ができたら、事実が本当に事実なのか？の調査と対応です。

Datadog APM を導入して、調査結果がわからない。という答えを回避するために導入しました。

私自信、Micro Service Architecture が初めてでかつ、APM の導入未経験だったので、最初は意味あるのかな？と思っていたのですが、Micro Service というサービス間が細かく分離されているアーキテクトではやはり Datadog APM は強力な武器となりました。

Service 間の Trace 情報(どのようなサービス間経路でアクセスされているのか)
その時に発行されて Query がどの位時間がかかっているか？

等、調査をするにあたって見やすいです。

エラー調査は属人化しやすく、孤独な闘いになるケースが多いです。
その時に

調査がしやすい武器
調査結果(事実)を共有しやすいので、エラーのコラボレーションがしやすい

この2つが APM を入れた後の潜在的に秘めている良い所だと思っています。
APM で見える化できるんだ。すげー。というよりかは、チーム間コラボレーションで捗る所が大きかったです。

これは、良い意味で狙いよりも大きく裏切ってくれたな。という印象です。

SRE チームの立ち上げて 4 ヶ月後の世界の変化

さてここまでは、やってきた事実について、説明させていただきましたが、変化についても説明させて頂きます。

障害発生件数

元々の経緯は、障害が頻発している状況を改善したい。が目的だったので、まずはその結果です。

障害発生月	障害件数
2023年1月 - 6月迄	6.28 (平均)
2023年8月	3
2023年9月	3
2023年10月	3
2023年11月	1

SRE チーム発足後は、平均 2.5 件迄減少しました。

障害発生数の減少について大きかったのが、定期リリース後のデグレートのチェックを全チームの SRE でチェックを行っている事が一番寄与していると思っています。
実際にリリース後の変化で未然に防げたものは、いくつかあるとありました。

Alert 関連の通知の反応速度

Alert を約 18 倍増やしたので、Alert 疲れが発生するのでは？と思った方も多いかと思いますが、逆に反応速度は組織間全体で上がっています。

これは、ノイジーな Alert を根気強くこまめに調整をしたのも大きいです。
もう 1 つは SRE チームという組織的な集団と集まりを形成して、SRE とは？や 1 次対応の重要さを根気強く説いた事も大きいと思います。

重要なのは、Alert に敏感に反応してくれるメンバーの気持ちを全体で大事にして当たり前にしていく事です。
Alert の反応は集中したい時に、やはり疲れます。

でも、Alert に対して不感症を放置すると、やがて大きな障害を引き起こします。
7月の障害の教訓を踏まえて、ここは徹底しました。

Embedded SRE の皆さんには、大変だろうなぁ。。ごめんね。って気持ちがかなりありましたが、Embedded SRE が反応し続けてくれると、徐々に SRE 以外の方々も反応してくれるようになりました。

Error Toil の修正リリースが増えた

Datadog Dashboard で毎週状態変化の確認をする事で現実の Error Toil が邪魔をしている事実と自ずと向き合うようになります。
Toil の対応で一番難しいのは、致命的ではないのでアイゼンハワーマトリクスの「緊急ではないが重要な事」の事実関係を整理して提案をして、優先順位を徐々に上げることです。

SLI 指標を眺めることで、Toil を放置すると、この Toil がやがて致命的になる予測精度が上がっていきます。
重要なのは、Toil を潰す事ではなく、Toil を放置すると、いつまでにやばくなりそう。という予測力です。
これが優先順位をあげるきっかけになりますし、説明材料にもなります。

SLI の Metrics を読み解って予測力を養うには、時間がかかります。
ですが、時間をかけてでも必要な知識が少しずつ広がっていくと、Error Toil の優先順位があがってきた結果なのかな？と思っています。

そもそも Toil は、みんな嫌なのです。
嫌だけども説得も面倒臭いし、どうやって調査して良いかもわからない。

そんな人達を少しずつ知識と整理した事実で背中を押してあげた結果なのかな？と思っています。

最後に

さてこの 4ヶ月の変化を説明させていただきましたが、まだ SRE の基本的な事しかできていません。
現実問題として、ノイズデータが大きすぎて SLO は散々な状態な事実があったり、もっと奥の根本的なボトルネックの対応にもまだ動き出せていません。

ただこの4ヶ月で開発組織全体でも感覚的に感じられる程の状態の変化は起こせたのかな？と思っています。
(感じていなかったらごめんなさい)

最後にこの言葉を残して締めとさせて頂きます。

「推測するな、計測せよ」

明日のアドベントカレンダーは Miyake の「Cloud Run × Event-Driven Architecture の並列分散処理によるデータ処理高速化への取り組み」です。