手作業をなくそう！Backlog Gitチームの運用改善

Backlog Gitチームの中村です。去年まではBacklog Enterpriseチームにいましたが、今年からはGitチームへ異動してGit機能の開発・運用、「AI要約」機能の開発などをやっています。

Gitチームに異動してきてからオンボーディングを受ける中で、オペレーション作業時の手数の多さや、無視しているアラートがあることが気になりました。
Gitチームは以前から「タスクの属人化を減らそう」という流儀（ワーキングアグリーメント）を掲げていましたが、これらの要素は仕事の属人化につながると感じました。異動直後に感じたこれらの違和感をチームで共有し、少しずつ改善していきました。
また、Gitチームは3人で開発と運用の両方を担当しているため、運用にかかる時間が減れば減るほど開発に集中することができます。属人化を減らすとともに、自動化などによる運用の負荷軽減も行いました。

アラート対応の属人性の排除と信頼性の向上

オオカミ少年アラートの抑制

Gitチームが使用するTypetalkトピックには多数のアラートが通知されていましたが、すべてが即時対応を必要とするものではありませんでした。どのアラートが重要かを判断するためには、経験豊富なチームメンバーの確認が必要でした。

不要なアラートが通知されないよう、メモリアラートの閾値を調整し、夜間のバッチ処理中に起こるロードアベレージの増加に関するアラートは抑制するなどの対策を講じました。これにより不必要なアラートの数が減少し、アラートが通知された場合には必ず対応や調査が必要であるという明確な状態になりました。

二重アラートの解消

BacklogのGitサービスはAWSにホスティングしており、監視ツールとしてMackerelも利用しています。一部の監視項目については、MackerelとAmazon CloudWatchの両方で重複して監視されていました。このため、同じ問題に対して二重のアラートが発生する状態になっていました。

コストと使い勝手を検討した結果、重複している監視項目はMackerelに一本化することにしました。この変更により、重複するアラートによる混乱が減少し、監視の効率性が向上しました。

アラートメッセージからネクストアクションを明確化

BacklogのGitサービスでは、アラートが発生した際にTypetalkから開発者に通知が行われます。これまでは、アラートの対応方法がBacklogのWikiに記載されていましたが、どのアラートにどのWikiページが対応しているかは、Wikiの内容を事前に熟知していなければ判断が難しい状況でした。

この課題を解決するため、アラートメッセージに直接、対応するWikiページのURLを追加しました。この変更により、アラートを受けた人はメッセージを見るだけで、詳細情報や次に取るべきアクションをすぐに理解できるようになりました。

運用の手作業と属人性の排除

カーネルアップデートの自動化

BacklogのGitサーバーのカーネルアップデートは以前は手動で行われていました。テンプレートから作業手順書を生成し、レビューし、手動で作業するという流れで、全体で数日間かかる作業となっていました。

これをJenkinsジョブ化して、簡単に実行できるようにしました。基本的に手順書に書けるような作業はコード化できます。
カーネルアップデートの自動化は作業のボリュームが大きいため、「前処理」「アップデート処理」「後処理」のステップに分割して少しずつ自動化しました。大まかに説明すると、

前処理の自動化→後処理の自動化→アップデート処理の自動化→前処理・アップデート・後処理をつなぐジョブの作成→これらを複数のインスタンスへ一括適用するジョブの作成

という順番です。

※「JAWS FESTA 2023 in Kyushu『Backlogの成長と共に進化するAWSを活用したGitホスティングアーキテクチャ』」発表スライドより引用・加筆

部分的に自動化された状態でカーネルアップデートを実施するタイミングもありましたが、一部だけでも自動化されていると作業が楽になり、効果を実感しながら自動化を進められました。

現在は自動化が完了しており、数日かかっていた作業が数時間で完了するようになっています。大幅に作業が楽に、そして安全になりました。作業手順書の作成やレビューも不要になり、準備の負担も減りました。作業負荷だけでなく心理的負担も減り、必要なタイミングですぐにカーネルアップデートを実施することができるようになりました。

スイッチオーバーの自動化

BacklogのGitサーバーはプライマリとレプリカの二重構成になっています。

→ BacklogのGitホスティングにおける冗長化と負荷分散の仕組み

プライマリとレプリカの切り替え（スイッチオーバー）についても、以前は手動で作業していました。この作業も手順書を生成し、レビューし、手動で作業するという流れになっていました。

これもJenkinsジョブ化して、簡単に実行できるようにしました。
これにより大幅に作業が楽に、そして安全になりました。また作業手順書の作成やレビューも不要になり、準備の負担も減りました。
また、テスト環境を気軽にスイッチオーバーできるようになり、開発や検証でも役立っています。

リポジトリの整合性チェック作業の自動化

前のセクションに書いたように、BacklogのGitのデータは冗長化されています。この冗長化されたリポジトリの整合性をチェックする内部ツールが以前から存在していました。
このツールは問題発生時やメンテナンスの前などに手動で実行しており、手間も時間もかかる作業でした。

これをJenkinsジョブ化して毎日夜間に自動実行されるようにしました。
これにより手動の作業が不要になり、複雑な手順なくボタンを押すだけで実行できるようになりました。また、毎日リポジトリの整合性が保たれていることが確認できる他、問題も早期に発見できるようになりました。

自動化によって表れた問題

上記の整合性チェックの自動化に際して、古いテストデータや修復できない破損データなど、手動で整合性チェックをしていた頃はスルーしていた問題がアラートとなるようになりました。無視していい問題かどうかは詳しいメンバーにしか判断できない状態でした。
これらについて、リポジトリを修復したり、チェックツールに無視リストの機能を実装するなどして不要なアラートが発生しないように修正しました。
これにより、想定していない不整合のときだけアラートが発生するようになり、判断をする必要がなくなりました。

リリースジョブの改善

BacklogのGitサービスはテナントのグループごとに複数存在しており、アプリケーションの更新の際、以前はリリース先を1つずつ選択してリリースジョブを実行していました。リリースの進捗はチェックリストで管理していました。

ジョブを改善し、複数のグループを選択して同時にリリースできるようにしました。
どこまでリリースできているかなどを覚えておく必要がなくなり、リリースが楽になりました。

プッシュ型への移行による情報収集の自動化

朝会におけるメトリクス確認の廃止と効率化

朝会のルーチンの中に、AWSダッシュボードを開いてAmazon SQSデッドレターキュー（DLQ）の存在を毎日確認する作業がありました。ここでDLQが確認された場合、リカバリー対応を開始する流れでした。
しかし、DLQの発生時には既にアラートが設定されていたため、この毎朝の確認作業の必要性を再考しました。アラートの整理によりDLQ関連のアラートがより見つけやすくなっていたことも、検討の理由の一つでした。

その結果、朝会でのメトリクス確認を廃止し、代わりにアラート発生時に直ちにリカバリーを開始することにしました。この変更により、朝会のルーチンから1つの作業が削減され、対応時間も短縮されました。

ミドルウェア・ライブラリアップデート情報の集約

BacklogのGitはSSHプロトコルもサポートしており、Git自体だけでなくOpenSSHの脆弱性アップデートにも迅速に対応する必要があります。
これまで、これらのアップデート情報は社内のセキュリティチームのTypetalkのトピックに集約されていましたが、必要な情報を見逃さないために、GitとOpenSSHの更新情報のみをGitチームのTypetalkトピックに通知するためのBotを導入しました。

まとめ

アラートのリファクタリングにより、アラートに関する判断が不要になり、誰でも対応可能となりました。重要なアラートのみが通知されるようになったことで、アラートの有用性が向上しました。また、運用作業の自動化によりオペレーションミスのリスクが減少し、作業の迅速化が実現しました。作業手順の簡略化により、手順書の作成やレビューが不要になり、関連するタスクも大幅に削減されました。

手順書に記載できるような作業はコード化できると考えています。オペレーションの属人化や作業負荷の増加を防ぎ、開発のリソースを確保し続けるために、今後も引き続き改善や自動化を進めていきます。