はじめに
こんにちは！新卒入社3年目の塩田です。社内システムの開発・運用を担当しています。
先日「NIFTY Tech Talk #2 SRE【ポストモーテム・品質向上】」に登壇しましたので、
その様子を紹介していきます！
イベント概要
NIFTY Tech Talk は、ニフティ株式会社の社員が主催するトークイベントです。
本イベントではニフティ社員が業務を通じて学んだことを発信しています。
第二回目となる今回は、「SRE」というテーマに沿って座談会を開催しました。
- テーマ1：「チームでポストモーテムをどのようにしているか！？」
- テーマ2：「ポストモーテム導入後の効果は？」
- テーマ3：「障害の備えとしてロールプレイングした話、どのように周囲を巻き込んでいったか」
- テーマ4：「品質への取り組み、自動化や耐障害性について」
イベントの詳細については こちら の記事でも紹介しておりますので、ぜひご覧ください。
また、今回の Tech Talk の録画を YouTube にアップロードしております。
こちらもご覧いただけますと幸いです。
SRE とは？
SRE とは、Google が提唱したエンジニアのシステム運用論です。
詳しい内容については Google のページ をご参照ください。
内容レポート
オープニング + 会社紹介
はじめに会員システムグループグループ長 小松より、ニフティの会社紹介、ニフティでの SRE に対する取り組みなどを紹介しました。
ニフティでの SRE 活動は、各チーム内で SRE 担当を決め、SRE 推進チームが全体のサポートを実施しています。
SRE 推進チームが行っているのは「Embedded SRE」で、各チームで担当者が実施しているのは「The Google Model」というものになります。ニフティではこの組み合わせで浸透を進めています。
テーマ1：「チームでポストモーテムをどのようにしているか！？」
早速本題に入ります。
まず一つ目のテーマ「ポストモーテムの運用形態」についてディスカッションしました。
そもそもポストモーテムとは、障害報告書とは違い、読み手として現場のエンジニアを対象としている障害振り返りドキュメントのことを指します。
ディスカッション内では、ポストモーテムを導入した目的や、ポストモーテム共有会の実施方法、実施時の工夫点などが会話されました。
障害対応を実施した方には大きな負担がかかるため、精神的な支援も含めた体制づくりを心掛けているチームもあり、とても参考になりました。
ディスカッション内で話された、導入、運用状況を一部抜粋して紹介します。
<舟久保> 根本原因の検討、ドキュメント化を主な目的として導入しました。スクラム開発手法を導入していますが、障害が発生した際はスクラムイベントとは別で組み込んでいます。
<浅見> ポストモーテムにはインパクトや根本原因などを調べてドキュメント化する必要がありますね。
<舟久保> 私のチームでは、根本原因や対応の項目はチームで話し合って書くようにしています。
…
<浅見> 定期的なポストモーテム共有会を開くのも重要です。隣のチームに対して、自分の担当サービスではこんな障害が発生していてこんな対応をしていますという共有ができると、勉強にもなっていいと思います。
また、障害対応を頑張った人を MVP として表彰し、ピアボーナスを贈るといったこともしています。
<舟久保> ドキュメント化する際は、タイムラインを作成する必要があるなど負担がかかりますね。
<浅見> SRE 本（https://sre.google/books/）にも障害対応をした人にご褒美をあげるべき！と強く書かれていたので、導入しました。
共有会で MVP 表彰を取り入れ、ピアボーナスを贈る文化を形成しているチームもあり、とても興味深いですね。
テーマ2：「ポストモーテム導入後の効果は？」
2つ目のテーマ「実際にポストモーテムを導入して感じた効果」について紹介します。
ポストモーテムを導入することによってノウハウが見やすい形で多くの人に共有され、後の振り返りがしやすいという意見が挙げられました。
現在ニフティではチーム単位でのポストモーテム共有会にとどまっていますが、ドキュメントとしては全社員が見られる環境が整ってきています。今後はより大きい範囲で共有会を実施できる体制を整えていきたいですね。
<舟久保> 障害対応時に獲得できる重要な知見が集まるのがメリットかと思います。タイムラインを見れば全体の流れがつかめるので、当事者ではなくても重要な場所が分かります。共有会を実施することで、システムだけではなく運用面やチーム体制などの改善点が見えてきます。
<川上> 無意識に手を入れるのを避けてしまっている部分はあるので、ポストモーテムを見返すことで改めて見つめなおすきっかけになりますね。
…
<塩田> ノウハウが蓄積されるのが大きなメリットに感じています。エンジニア歴が短い社員にとってはノウハウが蓄積されている場がまとまっていると、見返すことで自分自身の成長につなげていけると思います。
<浅見> ポストモーテム共有会を実施していく中でも、共有会で得られたノウハウを各チームで実践した結果障害を防ぐことができているという効果が少し感じられる気がします。
テーマ3：「障害の備えとしてロールプレイングした話、どのように周囲を巻き込んでいったか」
3つ目のテーマは「障害ロールプレイング」についてです。
障害が発生した際の対応マニュアルを作成するのは一般的ですが、いざ障害が発生してみると予測できていなかった事態が発生するのは珍しいことではありません。
事前にロールプレイングをしておくことで、不測の事態を防ぐことができます。
実際にロールプレイングを実施した際のコミュニケーションの様子をご紹介します。
事象発覚から関係者連絡、担当アサイン、その後の対応とスムーズに進んでいる様子が分かります。
ファシリテーター 浅見が SRE NEXT 2022 に登壇した際に上記の内容を発表しておりますので、こちら もぜひご覧ください。
ディスカッション内でもいくつかロールプレイングを実施した体験談が話されましたが、事前に準備していたマニュアルでは対応しきれない部分がいくつか発生し、見直しにつながったとの意見が多数上げられました。
また、障害ロールプレイングは実施するのにコストがかかるという相談もありましたが、過去に発生した障害をトレースすることから始めるのがいいといった声もあり、参考になりました。
以下、ディスカッションの内容も抜粋してご紹介します。
<塩田> 社内勉強会がきっかけとなり「Slack で障害が発生した際のロールプレイング」を実施しているチームがあります。実際に障害が発生した際にパニックになることを防ぐこと、事前に設定していたフローに考慮漏れがないかをチェックすることを目的として実施しています。実施した結果、代替ツールの仕様が変更されていることにより若干の混乱が発生し、フローを一部見直すきっかけになったとのことです。
<浅見> ロールプレイングで気づきが得られたとのことですが、私のチームで実施した際も「これを見ておかなければいけなかった」といった気づきがありましたね。
<舟久保> 実施してみたい気持ちはありますが、実施するまでのハードルが少し高い気がします。
<浅見> 最初は過去に起きた障害をトレースする形で実施し始め、慣れてきた段階でこれから起こるであろう障害を再現する方式を取りました。過去に起きた障害を振り返るだけでもいいと思います。
テーマ4：「品質への取り組み、自動化や耐障害性について」
4つ目のテーマは「品質への取り組み」についてです。
各メンバーの所属チームにて、どんな取り組みを実施しているのかをディスカッションしました。
SLI / SLO を設定し、ダッシュボード上で管理できるように設定しているチームも複数ありました。
SLI / SLO の設定やダッシュボードの作成ににおいて、アーキテクチャやノウハウなどの詳しい部分についても今後ディスカッションしたいですね。
<川上> 月一でパフォーマンス会を実施しています。システムに SLI / SLO を設定していて、ダッシュボード上でこれらの値をチェックしたり、リソースの遷移グラフを確認しています。また、即時対応が必要な問題なのか、潜在的な問題がないかなどを議論しています。
<浅見> SLO を見ながら定期的に問題を確認する場ができているということですね。異常があった際にすぐ気づける状態になっていて、とてもいいですね。
<塩田> 私の担当システムでは、Toil の洗い出し・優先度付けを行い、撲滅活動を実施しています。Toil を自動化し撲滅することで、オペミスのリスクが減り品質向上につながっています。
まとめ
今回の Tech Talk では、ニフティで SRE がどのように展開されているのか、また各チームでどんな工夫を凝らして運用しているかをディスカッションしました。
1 時間という短い枠でしたが、他チームで運用している内容やノウハウが次々と出てきたので、大変貴重な時間となりました。
今後も NIFTY Tech Talk は継続して実施していきますので、ぜひご参加ください。
