13
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

本番環境を人間から守るために

Last updated at Posted at 2019-10-29

ある日のできごと。

1 モジュールの改修終わったから、開発用の環境でテストすっぞ!
2 よっしゃリリース完了!
3 あれ、開発環境でテストしても改修版反映されていない?
4 うげー、本番環境にリリースしてんじゃん orz...
5 ユーザーからめっちゃ問合せ来てるんだけど・・・(夜逃げじゃ)

システムの運用保守を経験したことがある人なら、コトの大小問わず1度は経験したことがあるのではないでしょうか。
クラウド環境全盛の現代でも、ほとんどの場合において、開発やテストを行う開発環境と、実際にサービスを提供する本番環境は分けているのが一般的かと思います。ややクラシカルな表現かもしれませんが、以下のようなイメージですね。

  • ローカル環境:コーディング、単体テスト
  • 開発環境/テスト環境:結合テスト
  • ステージング環境:総合テスト、リリース準備
  • 本番環境:実際にサービスを提供する環境

意図しないモジュールのリリースや、データベースの更新は「事故」です。事故を起こすのは、多分100%人間なのですが、なるべくなら事故は起こしたく無いのも人間です。自分も含めたそんな人のために、本番環境を自分たちから守る事故防止策をサクッとまとめてみました。

リリース作業

リリース手順書を用意する

人は間違うという前提でリリース手順書を用意しましょう。人の記憶など信用してはいけません。ポイントとして「誰にでもできる」レベルの手順書は目指さないことです。逆に細かすぎて手順を見落とす可能性大です。ある程度その仕事の常識を持っている前提で、簡潔に書いた方が良いでしょう。
防げる事故:事故全般

本番環境にリリースする際は2人以上で行う

たとえリリース手順書があっても間違うのが人間です。リリース手順書自体も間違っている可能性があります。
「リリースする人」と「リリース作業が正しいか確認する人」のペアで作業するようにしましょう。指さし確認も忘れずに。
防げる事故:リリース手順書の見落とし、作業の誤解

査証(エビデンス)を残す

画面キャプチャーやログなど、作業を正しく行った査証を残すようにしましょう。後で問題が発生したときに身を守ることができますし、査証を取る段階で過ちに気付ける場合があります。作業時刻も記録すると良いです。
防げる事故:リリース作業の誤り、えん罪防止

想定外の事態が発生したら、とにかく作業をストップする

現場判断で作業を進めると、取り返しのつかないことになりかねません。分からない状況になったらいったん作業をストップし、いわゆる「有識者」と共に理由を明らかにすることを優先しましょう。ここで有識者とは「何をもって有識者とするのか」という新たな課題が発生するのですが、いったん置いておきます。
防げる事故:環境の破壊など

事前準備を十分行う

ほとんどの場合、本番環境へのリリース作業を行える時間は限られていると思います。
時間が限られる->緊張する->ミスを起こす、というのは事故の王道です。
リハーサルや作業の準備をなるべく事前に行い、余裕をもってリリースできる状況を作りましょう。
防げる事故:緊張からのミス

リリース作業の自動化

Jenkinsなど、いろんなツールがあると思います。時間が限られた状況での人間の作業はなるべく減らす用にします。
防げる事故:事故全般

データベース

開発環境と本番環境でデータベース名(スキーマ名)を変える

ぼーっとして、開発環境で作業するつもりが本番環境を触っていた、という事故を防ぎます。
防げる事故:うっかりミス

開発環境と本番環境でログインできるユーザー名を変える

こちらも同様です。防止策は複数あった方が安心です。
防げる事故:うっかりミス

システムへのアクセス

ブラウザから利用するWebシステムネタが中心です。

開発環境と本番環境でIPアドレスの体系を変える

こちらもぼーっとして、開発環境で作業するつもりが本番環境を触っていた、という事故を防ぎます。
防げる事故:うっかりミス

開発環境と本番環境でURLのパスを変える

本番環境が
http://1.1.1.1/service
だったら開発環境は
http://100.100.100.100/dev_service
にする、というような対策です。IPアドレスだけ違うと、開発環境のIPアドレスを入力したつもりが本番環境にアクセスしていたという幻のようなことが起きます。
防げる事故:うっかりミス

ブラウザのオートコンプリート機能を無効にする

オートコンプリートで補完されたアドレスを無意識に使ってしまうミスを防止します。
普段使う端末では無いと不便なので、開発環境や本番環境のブラウザなど限定になると思います。

セキュリティ

開発環境から本番環境への疎通を防ぐ

データベースの接続先を書いたリソースファイルを取り違えたり、更新を忘れたりするミスは「あるある」です。OSのファイアウォールで開発環境から本番環境へ疎通できないように、特定のIPやポート番号の信号をブロックします。間違えてメンテナンス用のリモート接続もブロックしてしまわないよう注意しましょう。
防げる事故:設定ファイル、リソースファイルの取り違え

開発環境と本番環境のネットワークのセグメントを変える

上記と同様です。ファイアウォール機器で通信制御をかけるのもありです。

開発環境と本番環境でOSにログインできるユーザーIDを変える

リモート接続やターミナルで、ぼーっとして接続先を間違うことはよくあると思います。IDを変えておくと、間違いに気付ける可能性が高まります。

その他

壁紙やログインメッセージを変える

Windowsの場合はでかでかと「本番環境!」と書いた壁紙を用意しましょう。SSHなどのターミナルの場合はログインメッセージを変更しておきましょう。

先輩SEに聞く

そこそこ歴史のある会社だと「ミスを防ぐ7箇条」の類がきっとあるはずです。なんか社訓とか覚えるテイストがして嫌かもしれませんが、素直に受け入れると良いことがあると思います。あと、先輩SEに失敗談を聞くのも良いですね。飲み会の席だと長くなるのは温かい気持ちで受け入れましょう。

終わりに

いったん以上です。思いついたら追記しようと思います。そういえば、大昔のホストコンピューターの時代は、Enterキーと実行キーは別だったような気がします。実行キーはちょっと離れたところにあり赤くて押すのに緊張するようにできていました。1つの要素に複数の役割を持たせるのも事故の原因ですね。

いづれ事故は避けたいものです。人間がいる限りは。

13
14
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
13
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?