はじめに
私は現在バックエンドエンジニアとして仕事をしていますが、過去インフラ（AWS・GCP）の構築・運用改善業務をしていた時期がありました。
ただ明確に SRE チームに所属していたわけではなく、なんちゃって SRE 状態でした。
そこで、今後 SRE のポジションで参画する可能性も考えて書籍『SRE をはじめよう』を読んで心構えから学んでみようと思いました。
インフラを経験した立場から刺さったことをまとめてみたので、誰かの参考になると嬉しいです。
※ 私の独自認識もあり正確ではない情報も含まれている可能性があります。ご容赦ください。
レジリエンス工学との関係
本書のいたるところで レジリエンス工学 が言及されており、著者のこの学問への愛が溢れています。
レジリエンス工学とは、 IT エンジニアリング領域に限った話ではなく、もともと航空や医療業界などの高度に複雑でリスクが高い分野で広く活用されているものです。
システムや組織が予期しない事態・ストレスに直面した際に、適応し、正常な機能を維持し、場合によってはさらに成長する能力を研究する学問分野とのことです。
（レジリエンス=回復力）
↓ 巻末の索引からも頻出しているのが見てとれます。
SRE として働く上で、レジリエンス工学を学ぶ価値は大いにあると述べられています。
レジリエンス工学の考え方は、「障害は完全に防げない」という前提を受け入れた上で、どうやって迅速に対応し、システムを回復させるかに重点を置きます。
この視点は、システムの信頼性確保やエラーバジェットの設定などにも見られるように、SRE の業務にもかなり似通った面があり、納得できます。
私は本書で初めてレジリエンス工学を知りましたが、とても興味を持ちました。
SRE に限らず、Web システムの構築・運用に関わる全てのエンジニアは学ぶ価値があると思ったからです。
ちなみに本書を読んだ後、以下の本も読んでみました。
こちらは技術書というよりビジネス領域の本で、システムではなく組織のレジリエンスについて書かれていますが、困難の分析や対処法について学びがありました。
今後もレジリエンス工学は継続的に学んでいきたいです。
良いきっかけを与えてくれてとても感謝しています！
SRE のある 1 日
SRE にとって、「ああ、平均的な 1 日だった」と思うような日はありません。
第 8 章では、SRE の日常で行われている様々な仕事の「モード」について説明されています。
- インシデントモード
- インシデント後の学習モード
- ビルダーモード
- アーキテクチャモード
- コラボレーションモード
- 回復とセルフケアモード
どのモードの説明も興味深く、ぜひ本書をご覧いただきたいですが、個人的には「回復とセルフケアモード」が印象的でした。
回復とセルフケアモード
これは単一のモードというより、他の全てのモードに付随するもので、私たちの時間には回復とセルフケアの時間が必要です。
（最後にリストされているのは、重要度が一番下ということではなく特殊なモードという位置付けだからだそうです）
自分（と他人）を大切にしましょう。燃え尽きた人間は、信頼性の高いシステム構築に関わることができません。
と述べられており、非常に印象に残っています。
もちろんどのポジジョンでも言えることですが、
特に SRE という緊急性と瞬間的ストレスの高い業務を行うポジションでは、このモードが SRE を持続可能なものにしてくれるために必要不可欠だと同感します。
組織は SRE に対する期待値を上げすぎず、SRE に対し回復できる時間を設けてあげるようサポートしてあげるべきです。
成功のための組織的要因
11 章では、組織が SRE の導入を成功させるための 8 つの要因が書かれています。
個人的に印象的だった 1 つをピックアップしました。
共同作業できるか
SRE はあくなき共同作業 信頼性を向上させるには他に方法がないから
と述べられています。
これは SRE から周囲への働きかけもそうですが、組織全体（ビジネス側含め）が SRE と共同作業するという意識を持てるかの話であると認識しました。
SRE の共同作業が特に重要なのは、技術的な観点だけでなく、組織全体の目標と一致した形で信頼性と効率を向上させるためです。
ユーザ視点に立ったシステムの課題感を持つには、SRE だけで考えることはできなくて、チーム外との共同作業が常に必要である、ということだと考えました。
また「ローテーション」（開発チームメンバーが SRE チームで働き、SRE が他チームで働く）を設定することも有効です。
SRE はいかにして失敗するか
こちらは 12 章の内容です。
前章は成功要因でしたが、失敗のパターンを把握しておくことも、特に SRE 初心者や SRE をこれから導入していく組織では重要だと思います。
オンコールで終わる
SRE 文化の構築には、インシデントの処理とレビューに集中的かつ意図的に取り組む以外に方法はない
と述べられています。
一方で、SRE だけが全てのオンコールに対応し、SRE だけが賢くなっていくような状態は失敗です。
SRE が対応するオンコールの目的は、システムについてより深く学びその知識を信頼性向上に活用することです。
SWE 機能開発に集中できるように運用の苦痛やコストに対するヘッジをすることではありません。
SRE はオンコールから学び、よりよいシステムにむけて改善を重ねていくべきです。
SRE の仕事が「オンコールで終わり」という状況は避けるべきです。
そのためには、障害後のレビューを通して、SRE だけでなく開発担当者や関連する利害関係者も賢くなっていくような文化づくりをする必要があります。
成功の罠
SRE の取り組みが一時的にうまくいったように見えても、注意がいります。
持続的に効果を持たせるには、以下を忘れないようにする必要があります。
1.過小評価される
SRE の取り組みは、うまくいけばいくほど自分たちの存在が見えなくなってしまうという隠れた力学があります。（この話は前半の章でも何度か出ています）
そのため、SRE の取り組みと成果は組織全体に適切に伝えなければ、過小評価されてしまいます。
ここは個人的に非常に同感する部分であり、特にビジネス寄りの大きめの組織で起こりがちな気がします。
私自身も以前の職場で ArgoCD の導入でリリース時間を大幅短縮したり、継続的な技術負債解消したりなどの成果が PM（ビジネス寄り）に認知されておらず大きくモチベーションを落としてしまった時期がありました。
エンジニアは自分の成果を隠したがる人が多くこの現象は起こりがちです。個人もしくはその周りの人が、成果を可視化しきちんと組織全体に見える形でアピールする必要があります。
2. 英雄扱い
前述と少し矛盾するように見えますが、SRE の実績や周囲からの期待が大きすぎたために、英雄視されることも注意だと言います。
理由は、周囲とのあくなき共同作業を行う能力を弱めてしまうからです。（前述の成功要因「共同作業できるか」につながります）
SRE は実績をアピールしつつも、傲慢にならないようにバランスをとるように意識することが、継続性を維持する上で大事なんだと感じました。
顧客を忘れる
しばしば顧客ではなくコンポーネントに焦点を当てた監視や SLI/SLO を設定してしまいます。
本書では、業務の中で触れる色々なことが顧客視点でどのような影響を及ぼすか、常に自分自身や周囲に問いかけること、これが習慣として根付くまで続けることがおすすめされています。
ここも成功要因「共同作業できるか」にも大きく関連しますね。
これは SRE に限らず、技術が好きなエンジニアはみんな身につまされる話なのではと思います。
楽しむことを忘れる
運用業務を持続可能なものにするためには、楽しむことが不可欠だと述べられています。
これは全ての業務を楽しめという意味ではありません。ここ最近で仕事が楽しかったときのことを思い出せなければ、注意すべきシグナルになると言われています。
障害と向き合うことの多い SRE の業務は緊張と苦痛の連続だと思いますが、活力を持って積極的に仕事を続ける上では本当に共感します。
その他
第 14 章「Dickerson の信頼性の階層構造」 も SRE 初心者が学ぶべき箇所だと考えます。
これは、有名なマズローの欲求段階説を模して信頼性の段階構造を示したもので、階層の下が「強固」と見なされて初めて上の階層に進めるというものです。
信頼性の向上がうまく進まないと思ったら、この図を見返してみて、段飛ばしになっていないか確認してみようと思いました。
まとめ
SRE としての心構えは、まず何よりも「周囲との共同作業の意識をもつこと」だと感じました。
また、レジリエンス工学という分野にも出会えてとても良かったです。
これらは本書でも頻出しているワードでした。
参考