この記事は Qiita x 日本CTO協会共催！あなたの自己変革について語ろう！ Advent Calendar 2022 の13日目です。
今期シナジーマーケティングでは Synergy! 運用保守体制の再構築に取り組みました。運用保守は当たり前にやらなければいけない業務ですが、レベルを定め、体制を再定義することは、当たり前にはできないことでした。シナジーマーケティングの１年間の活動を「Give First」*1でご紹介します！
馬場 彩子（ババ アヤコ）モダナイズとマイグレーションから見えてきた課題
2022年1月。シナジーマーケティングは、インフラのクラウド移行（FROG プロジェクト）とアプリケーションのモダナイズ（NEWT プロジェクト）の真っ最中でした。移行と再生のプロジェクトは順調に進んでいましたが、運用保守の課題が見えてきました。
ひとつは、チームの問題です。 今までの機能開発では、プロジェクトごとにゴールを決めてチームを組成し、リリースしたら解散して別の機能の開発に着手していました。この方法では、プロジェクトはしっかり集中して進めることはできましたが、その後の長い長い運用保守に必要なシステムアーキテクチャと機能仕様の知識が断絶してしまいます。過去にリリースした多くの機能を一部の人しか（深く）理解していないため、障害発生時に対応可能なエンジニアが限定されてしまうことがありました。
もうひとつは、情報共有の問題です。 システム移行という大きなプロジェクトを遂行していると、トラブルがいくつか発生しました。私たちは、顧客とのコミュニケーションを実現する CRM サービスを提供しています。そのため、障害発生時は当社のお客様企業もそのお客様とコミュニケーションしている場合が多いです。誤った情報、タイミングを逸した情報は、システムの事故以上に当社のお客様の事業へ悪い影響を与える可能性があります。サービスを安心して利用いただくためには、システムで何が起きているのか・起きていたのか、社内・社外に正確な情報をタイミングよく共有することが必要だと感じました。
Ops も進化 させる
レジリエントなサービスへと進化させるために、2022年は運用保守の体制強化に取り組みました。
ひとつは、保守・運用人員の冗長化です。 システムの仕様や構造を理解するエンジニア、影響調査や復旧に携われる人員を増やすことにより、障害を早期に収拾できます。 ドキュメンテーションなどの情報共有や教育を強化し、体制の冗長化を進めます。
もうひとつは、情報共有体制の改善です。 障害やお問合せなど、問題が発生した場合はシステムの復旧以外にも、お客様とのコミュニケーションに必要な情報を迅速に正確に共有することができるか、が「事故」の影響を大きく左右します。障害対策責任者と協力して、マニュアルの見直しなどを行っています。
いずれも「障害の早期検知・復旧」に方針がシフトしていった証です。システムは壊れ、人はミスをします。そこは仕方がない。 ただそれを前提に、早期に検知し影響が小さいうちに復旧できるようにサービスをつくることが、再生後の Ops の Objective だと考えています。
さまざまな施策
さて、ここでは、上記を実現するために実施した施策をご紹介します。
プロダクトチームへの変更
まずは冗長化です。
開発では、「お客様からの問い合わせや障害があったときにはこの人に聞け！」という「エスカレーション一覧」が定義されています。2022年の初めは、人も偏っている上、新しく NEWT プロジェクト でリリースした機能のエスカレ先が定まっていない状態でした。そこで、あらためて保守運用対象のサービスをリストアップした上で、担当が一人しかいないサービスにエンジニアをアサインしたり、主担当の世代交代をし、技術の移管を進めました。
いままで担当システムがなかったエンジニアには、NEWT プロジェクトなどで馴染みのあるシステムの運用を明示的に担当してもらいました。それまでは「自分より理解している人が対応した方がよいだろう」と行動することに躊躇していたエンジニアも、アサインにより積極的に調査に参加するようになり、ぐっと冗長化が進みました。ただし、NEWTプロジェクト の対象ではなかった機能の技術移管が進まなかった、という課題が残りました。
旧機能の書き換えにより旧機能に関する理解が深まったことは、モダナイズプロジェクト NEWT の大きな成果でした。そこを評価し、８月の NEWT プロジェクト終了後もチームは解散させず、同じチームで新旧機能の開発・運用を実施する「プロダクトチーム」体制に変更しました。チームで、複数のサブシステムをみることにより、真の DevOps チーム・サイクルになったと感じます。
横断的なシステムの運用・保守分担など、依然として課題はあるものの、知識の蓄積や育成面で手応えを感じています。
情報共有フローの整備
当社では障害時はエンジニア - 営業間の情報をコントロールする「障害 PM」と、対外的な情報発信を管理する「障害責任者」、２つの役割を置いています。障害発生時はこの二人が中心となってことにあたるのですが、重要度の判別やコミュニケーションのルールが定められていたものの、詳細な手順が定まっていなかったり実態と乖離していたりする部分がありました。
そこで、障害 PM と障害責任者とで議論し、ルールの改訂を行いました。 また、ルールで補えない細かいオペレーションをマニュアルとして整備しました。
影響調査のテンプレート化
障害発生時に網羅的に現状を把握できるよう、影響調査のテンプレートを作成しました。障害発生時は障害発生ポイントだけではなく「この機能は正常に動作している」という情報も重要です。調査表を埋めることにより、正確に影響を推論できるようになりました。
障害時ボードの設置
Slack などでやりとりをしていると、「いつ、復旧したのか」「今、どうなのか」という情報が把握しづらくなります。大小関わらずトラブルが発生した場合は、障害時ボードとなる DocBase の記事を作成し、Slack を辿らずとも「なにがおきて、いつ復旧し、今どういう状態なのか」を社内全員が把握できるようにしました。
「振り返り」の実施
最後に、月次でプロセスの振り返りを実施することにしました。適当な粒度の情報が適切なタイミングで提供できたのか、「このタイミングでこういう情報があればよかった」「この調査はもうちょっとあとでもよかったが、復旧作業の邪魔にならなかったか」など議論し、テンプレートやフローの見直しを行いました。
「障害訓練」の実施
改訂した体制やフローは、「障害訓練」により評価しました。訓練を想定して、各チームで技術移管やフローを整備していきました。いわば「テスト駆動」開発です。
障害訓練 で学んだこと
さて、障害訓練は今年度に２回実施しましたが、学びの多いイベントになりました。
まず、上期です。新しくアサインされたメンバーに対してどういう知見を共有したらいいのか、なかなか悩ましかったです。そこで、最初の障害訓練は「課題を洗い出す」ことをゴールにおいて実行しました。 結果、システムや仕様の理解ではなく、機能復旧や調査タスクの優先順位づけやエンジニア間でのタスク分担、情報共有や議論、意思決定の流れがネックになっていることがわかりました。これまでベテランエンジニアが障害発生時に自然とやってしまっていたことが、全く言語化されていなかった。これは完全にベテランのミス。日常とは違う「障害対応」での、流れを共有しました。
上期の訓練を踏まえ、下期は、若いメンバーが障害対応のフロー、判断と実行を体験することをゴールに、訓練しました。前回のときに流れを把握したので、かなりスムーズに完了しました。
２度の訓練を通して、対応可能なエンジニアが増えたことにより、障害発生時の復旧と影響調査を広範囲で並行してできるようになりました。また、多くのプロセスが並行して走ると、情報は散乱してしまいますが、情報を統合するプロセスも新たに組み込まれたため、適切なタイミングで情報を提供できるようになり、営業も安心して顧客対応にあたれるようになったのでは、と感じます（そうであるとうれしい）
真のレジリエンスをもとめて
FROG / NEWT の再生プロジェクトを通して、アプリケーション・インフラの進化のスピードが向上しました。今後もスピードを緩めることなく、安心して利用いただける安定稼働するシステムを提供していきたい。そのための１年間の活動をご紹介しました。
ちなみに、障害訓練ではかなり大規模な障害を発生させたのですが、自動復旧が早すぎて、想定していたよりも影響が少なかったんですよね😝。障害発生担当が 「おかしいな.... もうちょっと影響あるはずなんだけど....」と裏でぶつぶつ言っていました。 システム自体も着実にレジリエントになっているので、今後もこのペースで成長していきます！
シナジーマーケティング株式会社では一緒に働く仲間を募集しています。
*1:CTO 協会の４つのバリューのひとつ
Give First / あなたの当たり前は誰かの学び
あなたの当たり前を共有しましょう！誰かが学び、あなたはフィードバックを得られ、結果的にあなたは多くのことを学べます。
