2022-05-14 - 2022-05-15の2日間で開催されていた SRE NEXT 2022に参加しました。 各社のさまざまな工夫や取組みが共有され、学びのある2日間でした。 運営、発表者、スポンサーのみなさま、ありがとうございました。
以下視聴したセッションのうち特に気になった発表の備忘録です。
How We Foster Reliability in Diversity
1日目の基調講演で、SREの難しさやどのように取組むとよいかの発表。
「SREの実践における重要な5つのステップ」において、「いきなりプラクティスを実践するのではなく、状況把握からはじめる」というのはまさに今の自分にあてはまる言葉だった。以前SREのプラクティス導入に失敗した身として、プラクティス導入のモチベーションが伝わっていなかったのでデザインドキュメントのような形で整理が必要と思っていたけど、それ以前に品質やプロダクティビティの現状が十分に共有されておらず、先に計測を始めるべきと取り組んでいる最中だった。「計測なくして改善なし」など、計測が重要なことは十分把握しているつもりだったけど、言語的な・定性的な現状把握だけでなく、定量的な把握が何よりも重要だと思っている(「定量的な」現状把握までは発表では触れられていなかったけど)。
また、組織の氷山モデルについて、単なる行動(Level1)を変えるだけでなく価値観(Level3)を変える必要があり、価値観を変えるためのアプローチが重要というのはその通り。行動を変えるだけならすぐにでもできるけど、それだとすぐに元に戻ってしまうので価値観から変える必要があると感じている。一方で、いきなりMVVの策定などに取り組んでも上手くいかないので、Level1から小さく始めて繰り返し、成功体験を積む必要があると感じており、まさに上からと下からの両面のアプローチが大切だと感じた。
1,000万人以上が利用する「家族アルバム みてね」のSRE組織は4年間でどのように作られてきたのか
ミクシィさんにおけるSRE組織の誕生とこれまで・これから取り組んでいくこと。
SREチーム設立直後の施策として、IaC整備や開発環境整備、ログ分析基盤の構築、S3最適化や各種セキュリティ施策の実施などは、まさに自分が今までやってきたことなので、今まで自分が取り組んできたことは大きく間違っていないと安心することができた。
一方で、自分たちと違うこととして見積りを含むスクラムをベースに開発に取り組んでいる点。障害対応などの割り込みやチームとして開発コストの見積りが難しいことから、自分たちはスプリントを切ってスクラムで開発することは諦め、カンバン方式で開発のフローに集中することにした。このあたりスプリントを切ることの工夫やメリットは気になるところ。
1年間のポストモーテム運用と、そこから生まれたツールsre-advisor
面白法人カヤックさんにおけるポストモーテムの取組み。
障害対応の知見をチーム間でも共有したいという目的の元でポストモーテムのフォーマット共通化およびそれを社内展開・ナレッジ蓄積するための取組みはすばらしい。自分はまずはナレッジの蓄積ができるようにポストモーテムのドキュメントを作成するところまではやっていたけど、それを組織に広めるために興味を引く一言コメント付きで展開するというルールまで策定しているのはよい取組みだと思った。ポストモーテムを書くかどうかの判断基準にエラーバジェットの消費量で判断するというのもわかりやすくよさそう。
また、ポストモーテムから導かれる再発防止をチェックリストにしたくないので、ツールで自動検知できるようにしたというのはフットワーク軽くすごい取組み。IaC側のコードでチェックするのが正道ではないかな、と思ったけどタスク定義のようにIaCされない部分をチェックしたいとか、社内固有のルールをチェックしたいなどの理由もあるようでなるほど。確かにtfsecやtflintで独自ルールを実装・管理するのは結構大変そうなので、このあたりさくっと対応できるのはすばらしい。
SRE チーム立ち上げから1年。気づいたら SRE っぽくない仕事まで貢献しちゃってる説
ビットキーさんにおけるSREとしてやってきたこと、SREっぽくないけどやってきたこと。
プロダクトチームをスケールさせるためにSREチームを立ち上げ、SLI/SLOやセキュリティ,テストなどを整備してきた上に、プロダクト開発における文化醸成やコーポレートセキュリティ、コスト削減などの相談がくるなど、プロダクト開発以外の相談事項がSREにくるのはあるあるなのかなと思った。コスト削減についても、具体的な閾値があるわけではなく無駄使いを止めたい、現在のコストが適切なのか判断できるようにしたい(コストの透明性を確保したい)という本来の目的からコストの可視化に取り組んだ点はまさに自分も同じことをしたので納得感が強かった。
SREの守備範囲が広過ぎてDevOpsの文脈以外の取組みもあるというのはその通りだし、コストやセキュリティなどは無関係ではいられなくても片手間でどうにかなる話ではないので、きちんと責務を分離して取組めるようになるとわかりやすい。現状だと Embedded SRE / Enabling SRE / Platform SREのようなわけ方はあるが個人的にはしっくりこないので、品質にコミットするSRE、セキュリティにコミットするSRE、コストにコミットするSREのような分類方法があっても面白いと思う。
Who owns the Service Level?
リクルートさんにおけるSREの実現について2020年の発表を踏まえたふりかえり。
いつもながら、自己完結を重視しこれを実現するのはすばらしいなと思いつつ、エラーバジェットを元にした行動には至れていないというのは少し驚いた。ただし、SLO違反したら機能リリースはストップするというのは難しいと思っていたので、これを幻想と言うのはすごく納得した。SLI/SLOはエンジニア以外との共通言語の役割で、認識共有やディスカッションにつながっていればそれで十分役目を果しているというのであれば、自分ももう少し安心して社内にSLI/SLOを導入できる気がする。
街じゅうを"駅前化"する電動マイクロモビリティのシェアサービス「LUUP」のIoTとSRE
LuupさんにおけるIoTシステムにおけるSREの取組み。
IoTなシステムにおける信頼性の計測に、CUJからSLI/SLOを策定するだけでは不十分なのでM2M通信の可用性を計測する必要があり、これをCMC(Critical Machine Communication)と名付けて電文解析・ログ管理して計測できるようにするという取組み。このあたりはまあ難しいよねと思いつつ、ハードウェアでは故障を検知した時点で手遅れなことが多い(修正に時間が掛かる)ので、故障予測などが必要ではないかと思ったら当然並行して取り組んでいるとのこと。 IoTシステムの場合、特に製品が安価になるほど監視や故障予測がコストに見合わずに、障害時にさっさと代替品を提供するという判断になりがちなので、CUJを重視してこのあたりを取り組んでいく取組みは非常に興味深い。
SRE NEXT全体について
動画視聴やQ&Aなどは特に問題なく、2日間通して気持ちよく参加することができた。これだけで運営のみなさまには大感謝。今後カンファレンスには発表する側か、せめてプロポーザルリジェクトな状態で参加したいところ。
ただ正直なところ、EventbriteやZoom Event Lobbyはあまり使いやすいとはいえず、このあたりもう少しどうにかならないかなとは思った。自分の普段利用の環境であるLinux Desktop(Ubuntu)はZoom Event Lobbyに対応しておらず、1日目開始直前の動作環境で利用できないことに気付いてあわててmacbook環境を準備した。Linux Desktopがこういった機能未対応なことはよくあるのでしょうがないけど、ちょっと悲しい。
