IT系オペミス対策に対しての持論

今日ツイッターで呟いた表題のつぶやきについて、割と反響があったので、ちょっと補足します。

ツイートした内容は以下の通り。あくまで私の持論なので、いろいろな異論があるのは分かっています。もちろんですが、個人の持論なので私が所属している会社の方針や考え方とはごっちゃにしないでください。

IT系オペミス対策に対しての持論

  • 生のSQL/DDL/DMLは本番テストに関わらず打たせない
  • 手作業がある時点で負け
  • rootになるな
  • 二重チェック、承認プロセスは厳しくするほど黙ってやるので逆効果
  • コマンド、コード、設定ファイルを読めない奴のレビューは全て無価値
  • ミスした手作業はまずなくせ
  • 運用でカバーは一番の悪手。絶対そこで誰かがミスする
  • 変更禁止期間とかやめろ、クラッカーは待ってくれないし、前後でトラブル多発する
  • トラブル防止の幟や横断幕を出してるところには近づくな

それぞれの項目について補足するとこんな感じです。

生のSQL/DDL/DMLは本番テストに関わらず打たせない

ここだけ具体的な話ですが、要するに手で打たせるなってことです。

delete xxx where yyy=zzz and aaa like '%bbb%'

例えば、上記のSQLを手打ちしようとして、xxxの後に「;」が入ったりエンターを押してしまったら終わります。
本番稼働しているシステムにこういう作業をやる事自体も本当は良くないですが、せめてこうやれって話です。(mysql部分は、pgsqlでもdb2でもsqlplusでもいいです)

mysql < sql.txt

手作業がある時点で負け

言うまでもないですが、どんな簡単なものでも手作業がある時点でオペレーションミスが発生するミスは0には絶対なりません。

rootになるな

一般ユーザーで可能な作業までrootで行うのは論外ですが、必要に応じてACL付加するなりして一般ユーザーで行えるようにすべきで、それでもどうにもならないものはsudoでやりましょう。

二重チェック、承認プロセスは厳しくするほど黙ってやるので逆効果

黙ってやる人に限ってミスをするので、ぶっちゃけ手間が増えるだけです。「うちの職場には黙ってやる人なんていない」っていうコメントもいただきましたが、それはこれまでの実績の話であってこれから将来も黙ってやる人が絶対出ないことは誰も保証できませんし、過去の話はこれから起こるかもしれないオペミスとは関係ありません。承認プロセスの有無や厳しさはオペレーションミスには何の関係もないです。
二重チェックはミスの発生確率は確かに減らせますが、何でもかんでも無用に二重チェックを強制するのは作業者もチェック者も緊張感を維持できないし、「相手が確認してくれるだろう」というかえって確認がいい加減になる方向に心理が傾くと思っています。

コマンド、コード、設定ファイルを読めない奴のレビューは全て無価値

言うまでもないですが、これらを補足するための説明資料などを必要とする相手のレビューは品質に寄与しません。分かってない人がレビューやっても、「二重チェックしろ」とか「スクリーンショットとれ」とか「xxxさんを自宅待機させろ」とかいう指摘しかどうせできませんから。「xxxさんを自宅待機させろ」は指摘としては有用じゃないかという意見があるかもしれませんが、それは管理・体制のレビューであって作業・システムのレビューじゃないです。

ミスした手作業はまずなくせ

「なぜそんな作業があるのか」「なぜ手作業でなければならないのか」を先に分析して作業そのものを無くす方向をまず検討すべきです。
作業がなくなるのであれば「なぜミスをしたか?」とか「どうやったらミスをしないか?」なんて考える必要ありません。

運用でカバーは一番の悪手。絶対そこで誰かがミスする

言うまでもないですね。「手作業がある時点で負け」と同じです。

変更禁止期間とかやめろ、クラッカーは待ってくれないし、前後でトラブル多発する

システムを止められないというのは理解できますが、システムの変更禁止は個人的に意味不明です。脆弱性とかを狙ったクラッカーはそんな事情待ってくれませんし、その期間をずらしたタイミングに作業が集中するので、マクロな視点ではトラブルが増えやすくなります。

トラブル防止の幟や横断幕を出してるところには近づくな

「へー、そうなんだ。すごいね。」としか感じません。横断幕程度で「そうだ!気を引き締めなきゃ!」と思う人がいたら、その考え方のほうが問題です。