SREの知識地図を読んだ感想

SREの知識地図を読んだ感想
#

この本を読んだ私は、ITサポートを3年、インフラエンジニアを7年、SREチームに所属してSREを名乗って7年ほど経つのでそれなりな期間になってきたのだけど、それでも全く自信満々にSRE本に載っていることを全部1から10まで実践できているとは思えないし、未だ分からないことだらけで日々試行錯誤をしている、そんな私アが読んだ感想をつらつらと書いていく。

1.2.2 過剰な信頼性を追い求めるとどうなるか
#

SREが過剰な信頼性追求を避け、ビジネスにとって適切な信頼性レベルを定義する

第一章から「SREとは」という、なかなかに難しい命題からスタートするのだが、その中でこの言葉はこの本の最も大事な所であり、SREの最もやりがいがある所だと私は感じた。

様々なアーキテクチャにはベストプラクティスが存在する。
しかしながら、そのベストプラクティスを特定のサービスに適用すれば必ず成功するわけでは無い。

例えば、過去にこんなことがあった。
開発環境は本番と同等でなければならない、なのでECSコンテナの台数も本番と同じだけ動かしているということがあった。
この時はこの会社は専任のSREが少数でいて且つイケイケどんどんだったからこんなことが出来たわけだけど、だんだんとコスト負担が生まれて最終的には2台だけで、本当に必要な時に増やすという運用になった。
当たり前と言えば当たり前なものの、このコントロールはSREが考えてコントロールできる部分である。
そしてそれを判断するのも、運用するのもSREしか出来ない。

「本番と同じ」という定義は何をもって同じとするか、SREが決められる裁量が大きなレイヤーだと私は考えている。
だからこそ世の中のベストプラクティスを知った上で、自社のベストプラクティスを模索していくことが真のSREという定義になるだろうと思う。

1.4.1 どのSREにも求められる単一のスキルセットはない
#

この段落ででてくる「SREの環境と求められるスキルセット」は、世のSREと名乗る人々が自分がどれに当てはまるかをあらわしていると感じた。
もう少し細かく分類すれば、アプリケーションエンジニア出身、インフラエンジニア出身などでも細かく分類できる所があるだろうなと思うので、そこから派生するスキルツリーみたいなのがあっても面白いかもしれない。

2章コラム SLOのレビュー会
#

この章では、SLI, SLOの定義について書かれているのだが、なんとなくSLI, SLOがすでに定着していることを前提としているように見えた。
個人的にはどう定着させていくかというのが最も難しい課題だと感じていてその説明はなかったものの、そのほぼ答えと思われるものがコラムにあった。
それが「SLOのレビュー会」である。

SLI, SLOが意味あるものとするために、SLI, SLOの話だけをMTGでしがちだがそうではなく、リリース計画やインシデント分析と一緒に話すことが最も重要であるのだと気付かされた。
正直SLI, SLOと言われてもPOやPMはエンジニアではない場合が多いので、重要だということはわかっていてもなかなか自分ごととして紐つけるのは難しいのだろうと思う。
そこで、リリース計画やインシデント分析に紐つけることでなにがどう影響してどのような結果になったというのが見えてきて、SLI, SLOがそれらに紐ついていくのだと思う。
これの答え合わせは私がSLI, SLOをあらためて導入したいというモチベーションが生まれた時やチームミッションとして命題が与えられた時だろう。

3.3.2 効果的な通知の原則
#

通知は「次に何をすればいいか」がわかる内容であるべきです

なかなか難しいものの、障害対応などにはかなり有用であるし、そこに記載していくことがチームのナレッジになるだろう。
また、参画して日の浅いメンバーでも障害対応を眺めるだけじゃなくて、一緒に対応していくこともできそうである。

3.6.4 社内での継続的な取り組み
#

ツールを見る習慣づけ

前職では、毎朝のチーム朝会でDatadogのダッシュボードを全員で眺めるようにしていた。
その結果、各メンバーとどう対応していくか、どう対応したか、どんな課題があって何が出来ていて何が出来ていないなどの会話が盛んになった。
実際、攻撃が増えていると気が付くこともできるようになったし、そもそも自社のアクセスの傾向をかなり正確に理解できる機会にもなったので私の中で成功体験として認識している。

4.5.1 ポストモーテムの運用
#

ポストモーテムを実施する基準を決める

この段落には「表4.1 障害重要度とポストモーテム実施基準」という表がある。
私も以前、ポストモーテムの形骸化を感じ、インシデントレスポンスのミーティングで知ったインシデントレベルを定義してそれをポストモーテムの実施基準に当てはめることを提案したことがある。
早速チームメンバーがその定義を記載してくれたことで、なんでもかんでもポストモーテムに投げ込まれていたものが、明らかに顧客影響のないようなものは実施から除外されただけでも効果はあったのではないかと思っている。

5.6 Runbookの作成と活用
#

Runbookとは障害発生時の対応の手順書やトラブルシュートの方法を記載したドキュメントのことらしい。
なかなか最近はオンコールもほとんどないので、それほど真剣に取り組まなくなってきてはいるものの、やはりこのような取り組みは必要である。
昔は障害があるたびに自分用のメモを残して対応していたが、やはりそういったものを積み重ねていけば、自動化して自分で対応しなくてもよくなるかもしれないのでまずは手順書に残していくのが大事だろう。

表6.2 オーバーヘッドの作業
#

トイルではないが、エンジニアリングの時間を奪うものというのは日々の業務に散らばっているものである。
日々の業務のなにがトイルでなにがオーバーヘッドなのか、本当に必要なのかどうか、必要でなければ整理したほうが良い。
しかしトイルと同じで、過度な自動化や整理は余計な負荷を増やしかねないので普段から意識したほうが良いのだろう。

7章サービスのリリースを事前にレビューする
#

正直、この章はあまり理解ができなかった章である。
記載内容の意味は理解出来たものの、これは具体的にはどういった活動を示すものなのかがわからなかった。
例えば、大きなリリースの前にセキュリティチェックをセキュリティエンジニアに依頼するというのを聞いたことがあるが、そういったものを指すのだろうか？
それともPRのレビューテンプレートで特定機能については、特定チームの誰かにもレビューしてもらうとかそういったものも含まれるのだろうか？

8.4.3 中央集中型
#

小さな組織のSREだと、ある程度はSREが横断的な対応をするようなこの形になりやすいかなと思ってはいるものの、アプリケーションエンジニアがある程度クラウドも触れると小さな組織でもProduct SRE的に色々やっているというようなパターンも多いのでは無いだろうか。

個人的に思うに、中央集中型は中央集権型になりやすい構造でもあるので、そのバランスをどう制御していくかもSREの手腕によることが大きいだろう。
強い権限を持つことに甘んじてはいけないと日々自戒の念を込めている。

9.2.3 積極的なコミュニケーション
#

SREのベストプラクティスを実践するのではなく、まずはいろいろな人とコミュニケーションを取り、その会社にあったベストプラクティスを実践していくのがやはり大事だ。
ともすれば一人で黙々と作業しがちになってしまうし、あれこれアプリケーションエンジニアがやっていることに口を挟んでストッパーになりがちなのだけども、なぜそうするのかお互いにコミュニケーションを取ることで壁が無くなっていくことでより最適な解を模索できると私は実感している。
知識地図ではあるものの、このような段落があったことはとても良いなと思う。

最後に
#

各章について、振り返りながら感想を記載していった。
まぁそうだよねと思うこともありつつ、SREの私としては日々の業務で感じがちでふと考えることがほとんどが綺麗に言語化されているというのが率直な感想。
知識だけじゃなくて、かなり実践的な、人々や各会社が経験したことなどがSRE本から踏み込んだ形で内容が盛り込まれた書籍だと思った。
もちろん、この本に記載されていることだけが正解ではないだろうけど、少なくともSREの知識としては教科書になりえるのではないだろうか。

何を話すにも一回この本をベースにしてから、深掘りしたいなとすら感じているほどに良いコンテキストの共有になりそうである。
これからSREを目指す人、今もSREをやっていてSREとは？と改めて考えたい人はぜひ手に取ってほしい。
もちろんSREだけじゃなくてアプリケーションエンジニアや組織運営に携わる人など色んな人に読んでほしい。