こんにちは。Backlog課Git Teamに所属している@maaaatoです。
趣味は筋トレと漫画を読むこととアニメを鑑賞することです。最近はまちカドまぞくという漫画にハマっています。登場人物の桃というキャラクターが筋トレ好きなキャラクターなので推しです。
さて、このブログでは今年の4月に開催されましたNuCon Mini 2022 Springにて発表しました「チームでサービスの運用をうまく支えていくための取り組み ~SREと共に~」の内容について、補足を交えながら現在どういう取り組みを行っているのかについて紹介したいと思います。
目次
発表資料について
当時の発表資料とNuCon Mini 2022 Springで登壇した際の動画のリンクを埋め込んでおきますので、もしよろしければ御覧ください。
発表資料
「チームでサービスの運用をうまく支えていくための取り組み ~SREと共に~」
ちなみにこちらの動画では発表前にジョジョネタを盛り込んでいます。もしジョジョが好きな方がいましたら何部のセリフが使われているか当ててみてください。答えは当記事の最後にあります。
過去のGit Teamの体制と課題
Git Team誕生前
BacklogのSRE課にBacklogのGit機能の開発するメンバー1名を包含していました。メンバーはアプリケーションの開発・保守をメインで担当し、BacklogのGit機能に関連するサーバーの保守（kernel updateなど）はWebOperationが担当するという作業分担をしていました。
WebOperationチームとはBacklogを構成するサーバーやミドルウェアなどの運用保守を担当し、Backlogのサービスの信頼性を高めることを責務としています。
この体制の課題としては以下の点がありました。
- BacklogのGit機能の開発するメンバー1名では開発スピードの向上が難しい
- アプリケーション以外にもインフラ周りのアーキテクチャのアップデートも行う必要がある
WebOperationのメンバーと共同することも可能でしたが、Backlogのその他の機能に関わるサーバーの運用・保守も担当しているとリソースをBacklogのGit機能に集中させることが難しい状況でした。
Git Team誕生後
そういった課題や状況を鑑みてBacklogのGit機能の開発にフォーカスすべくフィーチャーチームとしてGit Teamを作るという大きな決定がなされました。WebOperationに人員が増えた後、私はGit Teamに異動しました。
取り組んだことについて
Git Teamに異動するにあたって以下の2点について取り組もうと考えていました。
- 「自分たちが運用しているアプリケーションの現状を把握する」
- 「運用面で抱えている課題を解決する」
自分たちが運用しているアプリケーションの現状を把握する
突然ですが、私はアプリケーションの信頼性を高めることはお客様への価値提供に貢献すると思っています。ここでいう価値とは、「アプリケーションを利用してくれるお客様のビジネスの発展に貢献できるために我々が提供できる全て」＝価値と定義します。（あくまで個人の意見です）
信頼性を高めるためにはまず運用しているアプリケーションの現状を知る必要があると思いました。
では、アプリケーションの現状とはなんでしょうか。運用しているアプリケーションでこういった事はないでしょうか。
- アラートが毎日上がっているけど件数はわからない
- 上がっては消えを繰り返すアラート
- サーバーのメトリクスを見ても普段の状態をよく知らないので変化がわからない
つまり「運用しているアプリケーションのあるべき姿がわかってない」という状況です。
こういった状況は筆者も経験があります。自然とアラートに慣れてしまい、実は重要だったアラートを見逃してしまうことやメトリクスをたまにしか見ないので、じわじわとリソースを逼迫していることに気づけなかったことがあります。
そのような事がないように以下の対応を行うことにしました。
- 昨日発生したCRITICALアラートの通知とアラートの件数を集計（日別、月別）
- 毎朝チームメンバーで主要なメトリクスを確認する時間を作る
- クローズされたアラートの確認
昨日発生したCRITICALアラートの通知とアラートの件数を集計（日別、月別）
昨日発生したCRITICALアラートのサマリーを朝会前にチャットに投稿しています。これはアラートの振り返りを兼ねています。また件数を日別、月別でまとめることでアラートの増減を把握するようにしました。こうすることで体感で把握してしまっていたアラートを定量的に把握することができるようになります。
NuCon Mini 2022 Spring発表当時は手作業で集計を行っていましたが、メンバーのテリーさんがPagerDutyのAPIとGoogle App Scriptを使った自動集計ツールを作ってくれたお陰で対応コストが下がっています。
毎朝チームメンバーで主要なメトリクスを確認する時間を作る
朝会でメトリクスを確認する時間を取るようにしました。こうすることでチームでメトリクスを気にする癖が付きました。また、チーム内の会話でも「リリース後にメモリが増加している傾向にある」など普段の正常な状況からの異変に気付けるケースが出てきました。
また、特定の時間帯にMemoryが高くなっていることに気づき実際に調査・対応したケースもあります。この件については@vvatanabeさんがブログにまとめてくれるので公開を楽しみにお待ち下さい。
クローズされたアラートの確認
Gitリポジトリを保持するストレージ（Amazon EBS）の使用率の対応に貢献しています。日々作成されるGitリポジトリがストレージを圧迫して使用率がしきい値を超えるとアラートが通知されるのですが、GitリポジトリのGCや一時ファイルのクリーンアップなどでしきい値を下回りアラートが消えるケースがあります。実際にはしきい値間近ということで対応が必要になるため、クローズを繰り返しているアラートを見逃さず対応しています。
正直、どれも当たり前のことだとは思いますが信頼性は当たり前の事の上に成り立つと思っているので大切な事だと思っています。
運用面で抱えている課題を解決する
さて、次の「運用面で抱えている課題を解決する」ですが、アプリケーションの調査で不便なところがあればできるだけ早く対応をしたいところです。
具体的に不便に感じている所について開発者にヒアリングを行うことも大事ですが、実際に手を動かすことも効果的だと感じました。
チームメンバーと一緒に不具合の調査を行ってみるとアプリケーションのログが一箇所に集約ができておらず、サーバーにログインしてログを加工しながら調査する必要がありました。
こういった作業で困るポイントとして以下が挙げられます。
- ログファイルが複数箇所に分かれている場合は調査がしづらい
- ログの加工するコマンドが属人化する
- 調査結果の共有の仕方がテキストベースになりやすい
- 結果を可視化するには工夫が必要になる
Elasticsearchを用いたログ基盤の整備
このようなケースにElasticsearch+Kibana（Amazon OpenSearch Service）を利用することで解決しました。元々BacklogのログのBIツールとして利用している実績もあったため導入はスムーズでした。
Elasticsearchへのログの取り込みについての構成図は以下のようになっています。
現在取り組んでいること
プレモーテムの実践
プレモーテムの知見を溜めるためにチームでトライしています。改めてポストモーテムについて簡単に説明するとポストモーテムは発生した障害について障害の要因、時系列、暫定対応、恒久対応、振り返りなどをまとめ、発生した障害について学ぶための取り組みです。
一方プレモーテムはプロジェクトを進めていく途中で発生するリスクを洗い出し、どういう対応ができるか考えるための取り組みです。プロジェクトに限らず、 リリース予定の機能なども同様にプレモーテムの対象とすることができます。また、参加者はエンジニアに限らず、デザイナー、PdM、マーケティングなど関係者を集めて実施するケースがあります。
プレモーテムに取り組んでいる理由としては、以前、他チームで担当してくれているオペレーション作業で設定ミスが発生することがありました。そのポストモーテムの振り返りにGit Teamも参加したときに「この作業についてプレモーテムで認識を合わせておけばもしかしたら防ぐことができたのでは？」と思いました。
そのような背景があり、まずはGit Team内で実践して知見を溜めています。今後は他チームと一緒に取り組んでみたいと考えています。
また、プレモーテムについては理解を深めるにあたってはアセンド社の資料が大変参考になりました。
成長を続ける組織でのSRE戦略：プレモーテムによる信頼性の認識共有 SRE Next 2022
最後に
発表時の資料には具体的な説明や背景が抜けていたように感じていました。補足版として内容を補うことができればと思い、ブログを書いてみました。
取り組みやGit Teamについてもっと知りたい！と思った方はお気軽にTwitterのDMでご連絡ください！
ジョジョのセリフの答えですが三部、四部、五部、七部のセリフを使っています！全部正解した方はディ・モールト（非常に）良いぞッ！
