こんにちは！
AWSのカオスエンジニアリングの新サービスもリリースされ、オンコールトレーニングへの関心が高まっているのを感じています。delyのSREチームのjoooee0000(高山)と申します。
この記事は「dely #2 Advent Calendar 2020 - Adventar」の24日目の記事です。
昨日は新規事業開発をしている おっくー (@okutaku0507) さんによる 「KPI自動通知Botで始める 数字に執着するプロダクトマネジメント｜奥原拓也 / クラシルPdM｜note」でした。 KPIの必要性から具体的なBot化の知識まで具体的に解説されているのでぜひ参考にしてみてください！
はじめに
今回は、delyのSREチームがオンコールトレーニングを導入する3つの理由を紹介したいと思います。
delyのSREチームはこれまで、元々在籍していたメンバーと、2019年の10月に入社したメンバー2人体制で運用してきました。そして今年(2020年)の10月から、新しくSREとして入社したメンバーと育休から帰ってきたメンバー(育休前はサーバーサイド担当)の2人を足して4人体制になりました。現在、4人になった新生SREチームをチームとして再スタートさせるべく、チームミッションの再定義や役割スコープの決定、チーム体制の整備を行なっています。
その中で、delyのSREチームはオンコールトレーニングの導入を決定しました。なぜ導入することになったかを3つの項目に分けて紹介していきたいと思います。
(なお、この記事のオンコールトレーニングがさす具体的なトレーニングの内容はSRE本の28章 「SREの成長を加速する方法: 新人からオンコール担当、そしてその先へ」で紹介されているトレーニング内容をベースとしたものです)
オンコールトレーニングを導入する3つの理由
1. オンコール体制強化が急務
まずはシンプルに現状の体制でのオンコール対応に限界があるためです。
現在は元々在籍していたシニアエンジニアがメインでオンコール対応をしており、他のメンバーは補助という形でオンコール対応にあたっています。
そのため、メイン担当者がオンコール対応において単一障害点となってしまっています。さらに、delyのSREチームが運用を担当しているサービスはレシピ動画サービスの「クラシル」に加え、最近GCPからAWSへのリプレースを行なった「TRILL」という女性向けメディアも追加され2つになりました。なので、特に障害発生タイミングが被った場合に地獄がおこります。同じAWSのサービスを使っているため、AWS障害時などには容易におこりうることが想像できます。
「はい！その通りなのですが....」
delyのSREチームのメンバーは比較的新しいメンバーで構成されていることに加えて、サーバーサイドチームから異動したメンバーや、前職でがっつりオンコール対応をしていたわけではないメンバーも在籍しています。
そのような状況で、他のメンバーがオンコールのメイン対応を担えるようになるにあたり以下のようなハードルがありました。
オンコールのメイン担当者になるための3つのハードル
⑴ 新しいメンバーがオンコール対応をぶっつけ本番でやるのは危険
delyのSREチームが運用を担当している2つのサービスは、それぞれ月間利用者数千万人を超える巨大サービスです。 障害によりサービスが停止した際には大きな損害が出てしまうため、新しいメンバーがぶっつけ本番で対応するのは危険です。
⑵ シニアSREが優秀すぎて他のメンバーが実績を積む機会がない
この現象はオンコール対応にはよく発生する問題のようです。システム障害対応についての本にはこのようなオンコール対応の教育に関する問題について言及されています。
システム障害は、多くのシステムにおいて最優先の対応事項です。そのため、障害対応メンバーについては、社内で最もできる人間がアサインされます。あなたよりも経験が長いメンバーがいるのであれば、おそらく、あなたが障害対応を指揮する「インシデントコマンダー」になることはないでしょう。このような現場の場合、あなたはいつ経験を積むのでしょうか？それは、他にできる人間がいないときです。
(木村 誠明. システム障害対応の教科書.より)
これでは、メイン担当者の負荷が一向に減らず、永遠に単一障害点になり続けます。
⑶ 通常のプロジェクト業務だけではシステム全体像把握の効率が悪い/把握度が属人的になる
オンコール対応にはサービスが稼働しているシステムについての知識が必要になります。業務をこなしていく中でだんだんとシステムに関する深い知識が身についていくものだと思います。
しかし、アサインされたプロジェクトによってどこに知識がついていくか偏りが出てしまいます。 例えば、現在検証環境周りの再構築をやっているのですが、そこにがっつり関わっているメンバーは本番環境システム側に触れる機会が相対的に少なくなってしまいます。
また、自主的なリバースエンジニアリングや自主学習を通してシステムを理解することもできますが、自学のためどれほどの習熟度なのか判断する材料がないこと(どの程度の習熟度でオンコール対応できるという判断基準をもうけられない)と、効率が悪いことが問題としてあります。
この3つのハードルを越えるために、GoogleのSRE本を元にオンコールトレーニング導入を検討しました。
そこで疑問なのは、「そもそもオンコールトレーニングってどれくらいの効果があるの？どれくらいのチーム規模で導入するべきなの？」という話です。NetflixがオンコールトレーニングをやってAWSの障害に強かった話やGoogleのSREチームがオンコールトレーニングを導入している話などは有名ですが、あの規模だからできたことなのではと考えてしまいます。
しかし、Googleが出しているサイトリライアビリティーワークブックには、delyのチーム構成に似たオンコールトレーニングにおけるGoogleのモデルケースが存在していました。これは直接的な導入の理由になるわけではありませんが、似たチーム構成で成功例が存在していることは導入を後押しする理由になりました。
こちらはサイトリライアビリティワークブックのオンコール対応の章で紹介されていたモデルケースです。
マウンテンビューの Google SREチームの事例
<チーム構成>
● SREテックリードのSara
● 他のSREチームから来た経験豊富なSREのMike
● SREになるのは初めてのプロダクト開発チームからの異動者
● 4人の新規採用者(「Nooglers」)
<ストーリー>
数年前、マウンテンビューのGoogle SREのSara は、3 ヶ月以内にオンコールにならなければならないSRE チームを立ち上げました。
----中略----
チームが成熟していても、新しいサービスのオンコールになるのは挑戦であり、新しいマウンテンビューのSREチームは相対的に若いチームです。にもかかわらず、この新しいチームはサービスの品質やプロジェクトの速度を犠牲にすることなくサービスをオンボードできました。彼らは即座にサービスに改善を加えましたが、その中にはマシンのコストを40%下げたり、リリースのロールアウトをカナリアやその他の安全性チェックと合わせて完全に自動化したりといったことが含まれていました。新チームは 99.98%の可用性、言い換えれば四半期ごとにおよそ 26 分のダウンタイムをターゲットに、信頼性あるサービスを提供し続けてもいました。 新SREチームは、これほどのことをどのように自分たちで達成したのでしょうか?それは、スタータープロジェクト、メンタリング、トレーニングを通じてでした。
(サイトリライアビリティワークブック P149)
このチームは、オンコールトレーニングを実施することでたくさんのシステム変更を加えているにも関わらずSLOを達成し、サービスの信頼性を担保しています。そしてそれは、オンコールトレーニングによって成し遂げられたことということです。
また、この事例において具体的にどのようなトレーニングをおこなったかについても本に記載されています。
このような背景と最後の後押しが、オンコールトレーニングをdelyのSREチームに導入する意思決定につながりました。
2. SREの運用改善業務のアウトプット最大化
オンコールトレーニングは、シンプルにオンコール対応ができるようになることに加えて別の役割も果たすと考えています。それは、SREの通常業務をする上でも非常に重要な知識が習得できるという点です。
delyのSREチームの本来注力するべき業務はシステムの設計と運用の改善にあります。
改善には、下記のような工程が存在します。
①課題を発見する
②課題に適切な優先順位をつける
③適切な解決策を考えて実行する
ここで重要なことは、①と②の工程ができていなければ、どんなに③が優れていても影響は小さいということです。
よって、改善業務において①と②の工程がとても大事になってきます。つまり、チームのアウトプットを最大化するには、まず課題発見と優先順位づけの精度を高めていく必要があります。
そこで課題となってくるのが、delyのSREチームは比較的新しいメンバーが多いためまだシステムに対する知識にムラがあることです。特にシステムの全体を俯瞰して課題の優先順位づけを行うことにはまだハードルがあります。また、システムに内在する既知の課題を網羅的に把握する機会がありません。全員の課題発見のスピードを上げ、優先順位づけを行えるようになることで①と②の質を高めていく必要があります。
オンコールトレーニングを行うことにより課題発見と優先順位づけをする上で重要な知識が身につくと考えています。
オンコールトレーニングにはいくつかの種類ややり方が存在しています。それを大別すると、システムについての網羅的な学習 と障害をベースにした学習 に分類できます。
● 網羅的な学習
課題を発見するには、そもそもシステムについて知る必要があります。システムについて学習をすることにより、課題の発見/理解がしやすくなります。また、網羅的な学習により全体像が見えることで課題の優先順位づけの精度を上げることができます。
● 障害ベースの学習
障害ベースの学習を行うことにより、システムの現状の弱点を把握することができます。「システムの現状の弱点 = 課題」です。障害ベースの学習を行うことで、現状潜んでいる課題を知ることができます。
このように、オンコールトレーニングをすることが課題の発見と優先順位づけをスムーズにできる手助けをしてくれます。結果的に、オンコールトレーニングをすることでSREチームが出すアウトプットの価値を上げることにつながると考えています。
3. 新規社員がスムーズに戦力になれる仕組み作り
これまで、オンコールトレーニングを整備するとオンコール対応強化やSREの運用改善業務をする上でメリットがあるという話をしてきました。それにより、今後入社するメンバーにとってもスムーズに戦力になれる環境が整います。
さらに、新規社員を迎えるにあたりもう一つオンコールトレーニングを行うメリットがあります。それは、システムに関するドキュメントが豊富になるという点です。
delyにはもともと、在籍日数や立場に関係なく誰でも 活躍することができるうように情報の透明性を高くし、情報の非対称性をなくすという文化があります。
オンコールトレーニングで習得した知識をメンバーが ドキュメンテーションすることで現状のシステムの構成やモニタリング、ロギング、ロールバックの手順など豊富な知識が可視化されることになります。現状もドキュメントはかなり豊富なほうですが、オンコールトレーニングの導入によりさらに豊富になっていく予定です。これは、SREチームだけではなくサーバーサイドチームなど他のチームにとってもいい影響を及ぼすことが考えられます。
オンコールトレーニングを導入することで、入社後の戦力になるスピードを上げることができ、さらにドキュメントがそろうことでストレスなく業務にあたる環境作りが望めます。
まとめ
これらより、delyのSREチームではオンコールトレーニングを導入することになりました。オンコールトレーニングをすることはオンコール対応ができるようになるだけではなく様々なメリットがあります。
また、大規模なチームではなくても導入をすることができると考えています。 導入の仕方や実際になにをやっているかなどは今後のブログでまた共有していこと思います！
delyではSREメンバーを募集しています。@gomesuit @bababachi @akngo22 など愉快なメンバーが揃っていますのでご応募お待ちしております！
また、「クラシル Tech Talk」などのイベントも多数行っています。 エントリー前に開発部の様子を知りたいという方はぜひ覗いてみてください。ご応募をお待ちしております！
