本番作業の概要と課題
こんにちは、riddleです。今日はですね、私がSIer時代に遭遇した夜間の本番作業あるあるをご紹介します。
皆さん、本番作業やってますかね。本番作業というのは、SIerにおいてはお客様の環境を預かっていることが多いので、
そのお客様の環境に何か変更を加えたりとか、追加したりとか削除したりみたいな、いろんな作業をひっくるめて本番作業と呼んでいます。
本番環境に対する変更全部ですね。どんなサービスを運用しているかにもよるんですけれども、私が担当していたサービスは、
基本的にメンテナンスと呼ばれる期間が深夜3時とかに設定されていたので、その時間にあるということで、夜間作業が必須という感じでした。
また当時はですね、インフラエンジニアだったので、お客さんのデータセンターに行って何か処理をするということが当たり前でしたね。
一部違うところのケースもあったんですけど、大体はデータセンターに行くみたいな感じでした。
そんな感じで、私の経験と他の人から見聞きした話とか、エサイヤーであるよねっていう話を紹介したいと思います。
その前に皆さん、本番作業で何かが起こるってどういうシチュエーションかというと、何か手順が元々ありますと。
これは検証環境で動作チェック済みのやつです。
それを本番作業でテコテコってやるんですよ。
なので基本的には同じ環境でテストしてるんで問題が起きないはずなんですけど、問題は起きます。
もうね、いやこれはいろいろあるんですよ理由は。
イレギュラーがあるんですね。
あとはやっぱ人間がやるんでミスがどうしても出ます。
なので基本的に苦しい話です。
はい、まず1個目。
まず、何かしら事故が起きました。
そうしたら、1発目。
上司に電話します。
この時上司電話出ないんですね。
これありますね。
深夜の仕事なんで、3時から始めたとして4時とか5時とかにミスるんですよそういう時って。
そうすると普通の人間は4時か5時寝てるんですよね。
そこに電話して失敗しましたみたいな電話いきなりするんですけど、
まあまあ大体起きないんで。
上司に電話して起きない時はさらにその上の上司に電話して繋いで
そこからこういう風にしようと思うんですけどいいですかみたいな
めちゃくちゃ大変な調整が始まります。
一応問題が起こった時のためにここで問題が起きたらこうやって元に戻しますみたいなところまで
手順を用意してたりすることがあるんですけども
それを基本的にやっていいですかみたいな承認を取って元に戻すみたいな感じですね。
いやーもう元に戻す手順も練習はしてるんですけどね。
やっぱり戻すとなるとしんどいですよねいろんな意味で。
はいこれが1個目。連絡した上司起きてないですね。
2つ目いきます。
顧客への対応と障害報告
2つ目は翌朝朝市で顧客訪問をしてことの経緯を説明するですね。
はいこれもありますね。
これまあ会社とかチームにもよると思うんですけど
基本的に障害があったら翌日お客さんとかに説明しに行くんですよ。
これはあくまですよ。解決してた前提ですけど解決してなかったら作業も継続しつつ
お客さんの説明も行きます。
一応深夜からいろいろ障害対応してた人がそのまま説明するのが一番スムーズではあるんですけど
本番環境でいろいろトラブルが起きて直してるって最中だったり
そこで精神的にも肉体的にも削られてるので
その裏で上司とかちょっと頼りになりそうな先輩とかが
代わりに状況をヒアリングして資料を作ってくれて
朝市でお客さんのところに行って説明してきてくれます。
でまあさらにその上の例えば課長が行くんだったら部長も一緒に行くみたいな感じで
お客さんも朝からね想定で出てくるんですよね
こんなことがありましたとかどうなってるんですかみたいな
まあここではとりあえずまず一時報告でどういうことが起きて今どうしてるのか
今後どうするのかっていうまず軽いジャブみたいなやつですね
まあここはとりあえずもう淡々と説明して言われたことをはいはいって感じで聞く感じです
はい3つ目
これはですね障害が起きたのが例えばデータベースとかミドルウェアとかで
外部のベンダーのものを使っていたとしましょう
でそこがなんかバグを起こしてましたと
例えばデータベースだったらプライマリとセカンダリみたいな2台あって
切り替えるっていう手順だったんだけど製品のバグで切り替わらなかった
まあそういうことありますよね
そうなるとこれはですねベンダーを採用したのはSIRである我々なんですけれども
なので謝らないといけないんですよ採用したのが我々なんで
そうすると基本的には例えばベンダーA社としますが
A社にちょっとバグってたんですけどみたいな話をして
基本的にA社もうすいませんみたいな話になるんですけど
一応A社の本国本社の方にレターっていうのをもらってもらうんですね
レターっていうのはこういうバグがありました
こういう理由ですみたいなことがブワーって書いてある正式なやつがあるんですけど
それをもってしてこの会社がこういう問題を起こしました
受領お願いしますみたいな感じでお客さんのところに説明しに行くっていうね
これありますねこの儀式
再発防止策と運用上の問題
まあちょっと会社によるかもしれないです
がそういう話を聞いたっていう感じですね
はい続いて超厳しい再発防止策と水平展開が行われる
これもねありますね
いやーまあ再発防止策がね大事なんですけど
もうめちゃくちゃ細かいんですよね
例えば聞いた話だと基本手順書をですね
ターミナルVIとかで開いてその内容を別のターミナルでコピーして
実行してみたいな感じで普通やるんですけど
コピペミスしたみたいなことがあったらしいんですね
ここで言うコピペミスはすごい長いパス
オプトAABBBCCCDDDみたいな時に
ちょうどパスの長さが長すぎて
途中で開業されちゃってたみたいな感じの時に
開業含みでコピったせいで貼り付けたら実行されちゃったみたいな
そういう事件があって
この再発防止策はコピーしたものを一回テキストに貼り付けて
問題ないことを確認してから打つとか
長いディレクトリには先に移動してから作業をすることみたいな
なるほどみたいな
そういう感じですかみたいな感じの手順になりました
当時やってた現場はめちゃくちゃ厳しくて
新しいセルスクリプトとか作って動かすのも禁止だったり
今まで叩いたことのない
いわゆる標準のLinuxコマンドを叩くことすら不可だったんで
めっちゃ大変でしたね
水平展開っていうのはプロジェクトって別に一個じゃないんですよ
そのお客さんとやってるプロジェクトが
それが5個も10個もあったりして
他の本番作業とかあれば
そっちにも同じ対応しろっていう話になるんですよね
言いたいことは分かるんですけど
大変だなと思った記憶があります
次
復旧優先で監視アラートを止めたまま忘れ
二次障害に気づくのが遅れる
これもね聞きますね
本番作業の手順の中に監視アラートを止めるっていう作業があるんですよ
何かというと例えばサーバーの視覚監視
要するにサーバーがダウンしたら
アラートを上げるっていう仕組みがあったときに
本番作業中にサーバーを再起動したりとか停止したりする手順もあったりするんですね
その時に監視を止めてないとアラート飛んじゃうんで
その前に止めるんですよ
作業全部終わったら上げるみたいな
問題が起きる時って監視アラート止めて作業して問題が起きるんで
その後イレギュラーな復旧対応とかするんですけど
そうするとですね監視アラートを戻し忘れるんですね
戻さないと次の問題が起こってもアラート飛ばないんで分かんないんですよ
これはね二次生涯に繋がるんですよね
怖いなーいや怖いなー
この話してたら当時のこと思い出してしまった
はいちょっと次いきます
次
復旧後すぐ運用部門から原因究明報告を今すぐのコールが10分おきに届く
まあこれもありますね
これは復旧後すぐにだけじゃなくて
復旧中も飛んでくるんですよね10分に1回ぐらい連絡が
いやこれね確かに早く答え知りたいのは分かるし
進捗をリアルタイムで知りたいのも分かるんですけど
こっちもねどういう状況か100分分かってないんで
かつ本番作業でいろんなコマンドめちゃくちゃに叩くわけにもいかないじゃないですか
なんかねアプリがエラ入ってるからって言って
アプリにGDBみたいなの叩いてデバッグ取りに行くっていいのかみたいな話もありますし
1回ちょっとテストで再起動していいですかみたいなことも
本番で動いてたりとか気軽にできないし
何だったら再起動手順も細かくいっぱいあったりすることありますし
だからこれやられるときついんですよね
だいたい作業って2人でやるんですけど
1人がコールで時間取られてもう1人が作業するみたいになるんですけど
基本ミスしないように作業者確認者っていう体制でやってるんですよ
誰かがコマンド入力して確認者がOKって言ったらOKみたいな感じで入力できるんで
だから1人これに取られると余計ミス誘発しがちなんですよね手順もないし戻すときって
2025年の今にここまできつく運用してるサービスもそこまで多くはないと思いますが
私がインフラエンジニアだった13年前はこれが普通でした
ということで今回は私がSIR時代にインフラエンジニアとして見聞きした
本番作業で失敗したときあるあるをご紹介しました
ちょっと胃が痛い
ということでこのポッドキャストはハッシュタグURITで皆様からの
私も失敗したよエピソードを募集しております
別にコメントや感想もお待ちしております
また概要欄のですねGoogleのフォームのリンクからも同様に投稿可能となっておりますので
どうぞよろしくお願いいたしますありがとうございました
