本記事は架空の出来事を基にしたフィクションです。実在の企業・団体・個人とは一切関係ありません。

事件から一年がたった。
ここに、あの2日間に起こった出来事の一部をまとめる。

前置き

当社は自社サービスを運営している。
サービスで使用するソフトウェアシステムの開発・保守を協力会社に依頼していた。
デプロイメントはCI/CDパイプラインを通じて自動化されており、本番環境へのリリースは常にビルド済みのコンテナイメージを使用する運用となっていた。

時系列

12月11日

[当社・協力会社] ミーティングを行い、翌日のリリースについて確認を行った。

リリース準備は万端だ

12月12日

13:19 [当社→協力会社] リリース作業が終わってもよい時間になっても協力会社から連絡がないため、リリース作業の進捗を確認する
13:23 [協力会社→当社] リリース内容を問い合わせ

すでに事前の合意内容と齟齬が生じていた。昨日のミーティングは何だったのか？

13:43 [当社→協力会社] リリース内容を回答する
13:47 [協力会社] リリースを開始する
14:00 [協力会社→当社] リリースについて問い合わせる

「いまさら？」という質問で驚く。事前にリリース準備をしていれば不要な問い合わせだった。

〜ちょっとごたつくが省略〜

15:32 [協力会社→当社] リリース完了を報告
15:33 [当社→協力会社] 不具合時の前バージョンへの切り戻しの準備を依頼する

今までの経験から、リリースがうまくいかない可能性は十分にある。対策に余念がない。

15:35 [当社] 不具合を確認

ある意味で予想通りである

15:38 [当社→協力会社] 前バージョンへの切り戻しの開始を依頼する

ここから始まる

15:43 [協力会社→当社] 前バージョンへの切り戻しを承諾する
15:51 [協力会社→当社] エラーの原因が判明したと報告し、本番環境の動作確認を依頼する

前バージョンへの切り戻しを依頼しているにもかかわらず、なぜエラー調査や動作確認の話になるのか理解できなかった。

15:53 [当社→協力会社] 本番環境のバージョンを確認する
15:54 [協力会社→当社] 新バージョンであることを報告

前バージョンへの切り戻しが実施されていなかったことが判明！
前バージョンへの切り戻しの代わりに、本番環境でエラー原因の調査を行っていた！！

15:55 [当社→協力会社] 再び前バージョンへの切り戻しを依頼する
15:58 [協力会社→当社] 前バージョンへの切り戻しを承諾

この判断の遅れによるタイムロスは非常に大きかった。

〜このあと大変なことになるが公開できない〜

12月13日

9:59 [協力会社] リリース作業を開始する
10:12 [協力会社→当社] リリース完了を報告
11:37 [当社] 検証作業を完了する

これまでの経緯もあり、慎重に検証を行った。
これでリリースの失敗はあり得ない。誰もがそう思った。

14:55 [当社] 問題を発見する。社内で緊急に対応を協議する

午前中に検証を行い、正常に動作することを確認していた機能が動作しない。
数時間前に動作していた機能が、なぜ突然動かなくなるのか。
慎重に検証を行っていたため、協力会社の作業手順そのものに問題があるとは考えていなかった。

〜このあと大変なことになるが公開できない〜

協力会社の報告書

本番リリースの検証完了後、本番環境にSSH接続してDockerコンテナ内のソースコードを直接編集し、不要と判断した関数を削除したところ、当該関数が使用中であったことが判明しました。

最後に

現在では開発・運用はすべて社内で行っており、
当時からすると信じられないほど安定したリリースができるようになっています。