0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

この記事は以下のアドベントカレンダーに掲載しております
本番環境などでやらかしちゃった人 Advent Calendar 2025

おことわり

関係者の特定を防ぐために、団体や組織の情報を一部カモフラージュしております

背景と目的

背景

最近Qiitaで記事を書くことがなかなかできていませんでした。
毎年恒例のアドベントカレンダーで本番環境でのやらかしという面白そうなテーマがあったので重い腰を上げて書くことにしました

目的

タイトルにもあるとおり「サービス稼働停止」というのはシステムやアプリに触れている人間であればよくあった離、見聞きすることかもしれません。
今回は「思い込み」というある種のヒューマンエラーが招いたサービス稼働停止についてお伝えすることで、エンジニアの皆さんのためになればいいなと思います。

「やらかし」の概要

「やらかし」は私が入社4年目の時。
当時ある顧客の運営するポータルサイトの運用・保守(Aプロジェクト)を担当していました。
ある時、同じ顧客が運営するコーポレートサイトで使用している基盤システムのバージョンアップを担当(Bプロジェクト)することにもなりました。

なおAプロジェクトでは顧客からの要望がチケットで管理され、チケットごとに設計〜リリースを捌いていく流れで開発業務を行なっていました。
この時、下図のようなブランチ運用をしていました。

開発環境 検証環境 本番環境
Aプロジェクト mainブランチ stageブランチ prodブランチ

ある日Bプロジェクトの作業をしている時、何気なくいつも通りローカル環境でやったことをBプロジェクトで使っている開発環境にデプロイしました。

数分後、Bプロジェクトで改修しているコーポレートサイトを運用・保守を担当する方から
「サイトが落ちている。」と連絡があり、
コーポレートサイトの本番環境を確認すると500エラーで落ちていました。
image.png

自分のやったことを確認してみると、確かにデプロイは開発環境に間違いなくできていたのですが、
Bプロジェクトで扱っているコーポレートサイトでは下図のようなブランチ運用だったのです。

開発環境 検証環境 本番環境
Bプロジェクト devブランチ stageブランチ mainブランチ

同じmainという名前のブランチを使っているが、

  • Aプロジェクト(ポータルサイト)では開発環境で使用している
  • Bプロジェクト(コーポレートサイト)では本番環境で使用している

という状況でした。

すぐにコーポレートサイトへのデプロイをリバートすることで復旧することはできましたが、
障害発生から復旧までに要した1時間足らずの間でも多くの人がサービスを使うことができない時間を作ってしまいました。

なぜやらかしてしまったのか

「同じ顧客だし、ルールの概要は概ね一緒だろう」という思い込み

当時の私は1つの顧客、1つのシステムしか担当したことがなかったため、「同じ顧客であればシステムが異なっていてもお作法やルールは一緒だろう」という思い込みがありました。
そのため作業する環境のルールについてはBプロジェクトの担当者やコーポレートサイトの運用保守担当に確認せず作業してしまいました。

同じ「やらかし」を防ぐためには(自戒を込めて)

作業者であれば

作業者(=このお話における私と同じ立場)であればどんな細かいことやいつも当たり前にやっている作業でもルールは必ず確認しましょう。
「思い込み」のようなヒューマンエラーは仕組み化して防止しやすくなると考えます。
そのため新人だろうとベテランだろうと、初めて触れる環境では必ずルールを確認して、既存メンバーとの認識や理解を一致できるようにするべきと考えています。

指示者であれば

指示者(=このお話におけるコーポレートサイト運用保守担当と同じ立場)であれば、これは作業者で記したことの裏返しになりますが、ルールや作業の流れは逐一説明することを徹底しましょう。
今回であれば同じ顧客のシステムでもAプロジェクトとBプロジェクトではブランチ運用に違いがあることや、違いがあることに注意すること。といったところです。

また今回のお話にフォーカスしますが、「なぜブランチ運用に差異があるか」を事後対応として原因究明すべきです。
今後別の人が同じような状況下で作業をすることになるかもしれません。
そうなった場合に同じことを繰り返さないためにも、なぜ違いがあるかを分析して、正当な理由がないのであれば可能な限りルールは統一すべきです。
(統一できないのであればルール説明の時に注意事項として説明すべきですね。)

おわりに

思わぬ思い込みでサービスを止めてしまった経験についてご紹介しました。
誰にでも起こりうることですし、エンジニアをやっていく以上、いつでも起こりうることですのであまり自分を過信しすぎないよう、
ちょっとでも「あれ?」と思ったらしつこいくらいに確認して、事故は防ぎましょう。

後日談

ご紹介したブランチ名の違い(ブランチ運用のルール)は同一顧客の全プロジェクトで統一されました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?