こんにちは、CAMPFIREでSREをやっている岩崎です。SRE Advent Calendarということで、この一年でチームにSREを導入した話について書こうと思います。
SRE導入の経緯
自分が社内でSREとして活動を始めたのは一年ほど前に遡ります。当時のCAMPFIREは急速に成長しているベンチャー企業といった感じで、成長のスピードに仕組みが追いついておらず、色々と未整備な状態でした。
インフラは基本的に開発エンジニアが兼任するケースが多く、明確な担当者がいませんでした。また、運用ルールもあまり整備されていませんでした。
チームにSREを導入したというと華々しく聞こえるかもしれませんが、実際にはSRE以前の問題も多く、泥臭いことも結構やりました。私自身SREについて日々勉強している身ですし、SREは魔法の杖でも銀の弾丸でもありませんが、これから同じようにSREを導入しようとしているチームの参考になれば幸いです。
SREとは
SREとは Site Reliability Engineering もしくは Site Reliability Engineer を指す言葉です。直訳するとサイトの信頼性エンジニアリングということになります。Google発祥の考え方なので、ここでのサイトは元々Googleのことです。現在はなんらかのサービスの信頼性を制御するためのプラクティス群、といったニュアンスでしょうか。
Google SREの創始者である Benjamin Treynor Sloss 氏の「SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもの」という言葉を借りれば、Yet Another DevOpsということもできるかもしれません。
SREもDevOpsも明確な定義が曖昧な言葉ですが、SREはDevOpsの考え方を元にGoogleが築き上げたシステム管理とサービス運用の方法論といえます。そしてそれは「ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもの」であり、エラーバジェットやトイルなど独自の考え方を多く含みます。
詳しくはSREにとっての聖書である「SRE サイトリライアビリティエンジニアリング」に書かれていますので、興味がある方はぜひ原著にあたってみてください。英語ですが、Webで無料版も公開されています。
SRE サイトリライアビリティエンジニアリング
――Googleの信頼性を支えるエンジニアリングチーム
https://www.oreilly.co.jp/books/9784873117911/
Site Reliability Engineering
https://landing.google.com/sre/sre-book/toc/index.html
最初にやったこと
SRE導入にあたり、まず行ったのが運用ルールの整備と各種指標の可視化です。上記のように当時のチームには明確な運用ルールが存在せず、レビューのあるなしやデプロイの仕方もバラバラでした。そのため、必ずレビューを通す、デプロイルールを明文化するなどの基本的なところから整備していきました。
同時に可用性やエラー数、デプロイ数などをデータとして取得、可視化しSLO（Service Level Objectives = サービスレベル目標）を設定しました。このあたりはいきなり厳しい目標を設定するのではなく、まずはデータを取るところから始めました。
それまでは全く数値を取っていなかったのですが、改めて統計を取ってみると障害発生時のMTTR（Mean Time To Repair = 平均復旧時間）が長いことに気がつきました。ある意味で障害が起きるのは仕方がないのですが、工夫次第で障害発生時の復旧時間を短くすることは可能です。すぐに改善に取り組み、結果的にMTTRを5分の1程度にまで短縮することができました。
このように数値を取ることで改善するべき部分が明確になり、また開発と可用性のバランスについてビジネスリーダーと議論することができるようになりました。
定期的なSRE勉強会も始めました。基本的にはSRE本の輪読会を行い、時々Terraform勉強会などのイベントを挟みながら今でも緩く続けています。
また、当時のCAMPIFREは大量にリクエストが来ると処理が詰まりがちという問題を抱えていたため、合わせてそちらの対策も行いました。このように現実的に必要なことをやりつつ、徐々にSREの考え方を取り入れていきました。
トイルの撲滅
SREでは手作業で行われる成長を伴わないルーチンワークのことをトイルと呼び、トイルは各人の作業時間の50%以下に抑えるべきであるとされています。さもなければ、個人のキャリアの停滞やモラルの低下に繋がるからです。
SRE活動を始めた当時、ビジネスサイドからの問い合わせ対応やバグの修正をある人間が一人で行っていたのですが、忙しさに追われて本来その人がやりたいエンジニアリングの作業ができていませんでした。このままでは特定の人間に負荷が集中してしまいチーム全体として良くないと考え、話し合ってローテーション制にするようにしました。また、数回手作業で同じことをしたら自動化するなど、できる限りエンジニアリングで解決するように心懸けました。
下は自分が作った週ごとの担当者をお知らせするbotです。
ポストモーテム
SREでいうポストモーテムとは身内向けのインシデント報告書のようなものです。SREは、あるいはDevOpsは、あるインシデントが起こった際に同じ失敗を繰り返さないように組織的に学習します。
SRE本を参考にCAMPFIREでもポストモーテムを導入しました。また、今年の5月にはポストモーテム読書会を開催しました。
https://note.com/campfire_dev/n/nfe332057001e
継続的にポストモーテムを書くことで失敗から学ぶことができるようになり、同時に失敗した人間を責める空気がなくなりました（非難のない文化はポストモーテムにおける重要な要素です）。
とはいえポストモーテムを書くタイミングは難しく、あまり頻繁に書きすぎても辛くなってしまうため、気軽な情報共有はSlackに、大きなものだけポストモーテムを書くという形に落ち着きました。ポストモーテムの本質は失敗の知見を共有することによる組織的な学習なので、小さいものはSlackでも良いのではないかという考えです。そのチャンネルでは「どこどこの仕様は実はこうなので気をつけてくださいね！」といった気軽な情報共有が日常的に行われています。
エラーバジェット
エラーバジェットも取り入れました。といっても、一般的なエラーバジェットとは少し違う形で導入しました。
SRE本に書いてあるエラーバジェットはSLOと紐づいており、エラーバジェットを全て消費したら開発を止めるというものですが、今のチームの状況的に開発を止めることは現実的ではないため、Rollbarのエラー数を指標とし、エラーバジェットを超えた場合は積極的にエラーを直すという形にしました。
総リクエスト数に対するエラー数ではなく、Rollbarのエラー数を基準にした理由はそのほうがアプリケーションエンジニアが意識しやすいから、そしてエラーバジェットを超えた場合の対応が明確だからです。将来的には本来のエラーバジェットに近い運用に変えるかもしれませんが、しばらくは今の形でやってみて様子を見たいと思っています。
開発エンジニアに運用を意識してもらう
このように様々なSRE施策を導入してきましたが、開発エンジニアと運用エンジニアが対立したままでは根本的な改善は難しいものがありました。開発エンジニアのインセンティブはどんどん新しい機能を実装してリリースすることである一方で、運用エンジニアのインセンティブは可用性を高めるために可能な限り変更を抑えることだからです。そこで、開発エンジニアにも運用を意識してもらうという活動を始めました。
ある意味で上記のポストモーテムやエラーバジェットもその一環なのですが、先月から新しくスロークエリをSlackに通知するということを始めました。仮に新規開発で発生したスロークエリが原因でサイトが落ちた場合、そのチャンネルから該当のクエリを特定して実装した開発者に直してもらいます。これを始めてから開発者が常にスロークエリを意識した実装をするようになり、サイトの信頼性が高まりました。
開発エンジニアに運用を意識してもらう前提として、開発を指揮するビジネスリーダーとのコミュニケーションも欠かせません。可用性の責任を運用チームにだけ押し付けるのではなく、チーム全体として責任を持って開発と可用性のバランスを取ることが大切です。
「開発した人間が運用する」というのはAWSの「You Build It, You Run It」やNetflixの「Full Cycle Developers」に近い考え方ですが、今後ますます重要になっていくのではないかと思っています。
文化を作るということ
SREを導入するにあたり気をつけたことは、少しずつやる、チームに合わせてやるということです。ツールや仕組みにばかり気を取られがちですが、SREの、あるいはDevOpsの本質は文化運動です。GoogleのSREプラクティスをいきなり完璧に持ってきたとしても、それは単なるカーゴ・カルトであり、現場は混乱するだけでしょう。なぜならそこには文化がないからです。文化というのは時間をかけて内部で少しずつ育てていくしかありません。
文化は基本的に共同体独自のものです。極論をいえば、SREを本当の意味で実践できるのはGoogleだけであり、他の組織はGoogle SREを参考に独自のSREを作っていくしかありません。上のプラクティスの多くはSREを基調としつつもCAMPFIRE独自のものですが、そうならざるを得なかった側面とそれで良いのではないかという側面がありました。GoogleがDevOpsというインターフェースからSREを実装したように、CAMPFIREも試行錯誤しながらCAMPFIRE SREを実装していけばいいのです。
最後に、SRE本とともに私が大きく影響を受けた「Effective DevOps」から監訳者である吉羽龍太郎氏の言葉を引用させていただきたいと思います。
組織や人に目を向けると、同じものは2つとして存在しない。したがって、「これをやれば必ずうまくいく」という万能のソリューションも残念ながら存在しない。
〜中略〜
自分の環境であればどのように進めるのかを考えた上で、行動に移すと良いだろう。そして、何を考えてどう行動したのか、結果としてどうなったのかを、ぜひ組織内外で共有し、あとに続く人たちのためにストーリーを示して貰えればと思う。
この文章が誰かにとっての参考ストーリーになれば嬉しく思います。最後までお読みいただきありがとうございました。