KLab若手エンジニアの これなぁに?

KLab株式会社の若手エンジニアによる技術ブログです。phpやRubyなどの汎用LLやJavaScript/actionScript等のクライアントサイドの内容、MySQL等のデータベース、その他フレームワークまで幅広く面白い情報を発信します。

2009年03月

障害予防の 7 箇条

# 運用オペレーションの実務を経験された方は身に染みて分かっているし、 # それぞれのノウハウもあると思うけど、ジブンが経験したことを踏まえ、 # 自戒の念を込めて書いてみる。 本番運用中にもしも障害を起こしたら、その後始末はとても大変です。 関係各所へ連絡をして原因や影響範囲を調べ、障害報告書を書いて…あぁおそろしや。 ですから、本番運用でのオペレーションはできる限り慎重にし、手間をかけるべきです。 手間をかけても障害を起こした後の大変さに比べれば大したものではありません。 (ただ、障害発生後の後始末を通して得られる経験値は高く、さまざまなノウハウや文書作成能力の向上などは特典といえるかもしれません。;-) とはいえ、やはり障害は対外的な信用を低下させ、モチベーションも下がるので起こしたくないもの。 そこで、実際に(運用オペレーション時における)障害を防止するためにはどういうことに気をつければよいかということを挙げてみました。

事前にやること

事前の作業で本番環境でのオペミスを防止

1. 事前の手順書の準備

手順書のレビューも実施し、作業者が気づかなかったリスクが浮上すればそれに対して検討することもできる。 また、できる限りコピペできるような形にしておくと実際の作業時に便利だし安全。

2. 事前に本番環境と同一のテスト環境での実施・確認

このとき、ファイルのデプロイ元はこのテスト環境と本番環境で同一にすべき。 テスト環境で確認したら、以降本番環境に反映するまではリポジトリからアップデートしないこと。

複数の目でチェックする

障害予防の基本。 人間 1 人の注意力には限界があるので、できる限り冗長化することでチェック漏れを防ぐ。

3. screen を利用してオペレーションを共有

複数人で screen セッションを共有し、作業状況を確認する。 また、1 人しかいなくても screen は常に使用したほうがよい。 万が一、接続が切れても screen -r すれば続きを進めることが出来るし、その他いろいろと便利。 GNU Screen - Wikipedia http://ja.wikipedia.org/wiki/GNU_Screen

4. irc 等でオペレーション状況を実況する(コマンドとその結果をコピペとか)

状況を他のメンバーにも共有することで、問題が起こりそうな場合にも他のメンバーからアラートを出せたり、その解決をスムーズに行うことが出来る。

コマンド実行直前に

5. 指差し確認

ベタだけどオペミス防止効果あり。しかも 1 人でも有効。 実際に指で指すという身体の動作と確認内容を声に出す(そしてそれを耳で聞く)ことで今ジブンがやろうとしているオペレーションを再確認できる。 重要なコマンドを実行する場合などには特にお勧め。 指差喚呼 - Wikipedia http://ja.wikipedia.org/wiki/%E6%8C%87%E5%B7%AE%E5%96%9A%E5%91%BC

作業を反映後

6. 定型チェックと自由チェック

主にコンテンツサイト系運用でやるチェック。 定型チェックはテスト項目に従って一通りやるチェック。 自由チェックはその名の通り、自由にさまざまな遷移をチェック。 仮に問題が見つかったとしても発見を早めることですぐにリカバーできる。定期的に実施するのも効果的。

その他

7. 油断せず常に注意深くする。

障害の多くは油断から生まれる。 油断していつもの確認手順を省くといったことが日常化してくるとヤバイ
以上、いろいろなシーンを想像して挙げているので場合によっては適当でないものもありますが、なるべく多くを実践したいですね。 また、他に有効な方法やご意見などいただけると幸いです。 (追記) [2009-03-04] 同僚から意見もらいましたが、ある程度の定型的でまとまった作業はスクリプト化するというのもアリですね。さらに y/n 確認の仕組みがあるとよさげです。 [2009-03-06] 社内で次のような意見をいただきました。 ・スクリプトについては dry run する機能を最初から実装するとよい -> dry run 機能があるコマンドは必ず dry run して意図したとおりであることを確認するようにする "1. 事前の手順書の準備" について ・手順書には作業目的も書いたほうが良い -> 本当に *手順のみ* しか書かないとミスしがち -> 自分でミスに気づき易いという利点もある "7. 油断せず常に注意深くする。" の補足 よく展開でやらかす要因として、(悪い意味で)「手抜きする」というのがあります。 ・テスト環境での確認をとばす ・定型的な展開と思い、確認をとばす など また、タスクが積みあがっていたり、作業がマンネリ化してくるとやらかしがちなので、 単に "油断しない" というだけでなく、"油断しない" ための何らかの仕組みがあると良いですね。

デプロイ時に実況中継するIRCボット

ども、amo-kです。 先日デプロイ時に実況中継するIRCボットを作ったのでこれについて。 KLabでは通常、 テスト/本番環境に最新のプログラムソースコードを反映する際に 以下のような手順を踏む。 1.踏み台サーバにログイン 2.SVN Export 3.アーカイヴ作成 4.テスト/本番環境にアーカイヴをアップロード 5.テスト/本番環境のコマンドを実行し、アーカイヴ解凍、各Webサーバに同期 6.お掃除 通常はこれを1コマンドで実現するためにデプロイスクリプトを書いて そのスクリプトを実行する事でデプロイすることとなる。 その際に、デプロイした人はターミナルをチェックしていれば スクリプトの標準出力で進捗を把握できるが、たの案件メンバは解らない。 そこで、デプロイ実況中継をするIRCボットを作ってみた。 今回は特定のキーワードに反応したり、待機する必要がないので 各ステータス毎にIRCサーバに接続、チャンネルJOIN、レポート、切断ということをする 非常に単純なボットを作った。 以下、IRCクライアント画面サンプルとサンプルソースコード 工夫した点は特に無いが、ライブラリを使わずに TCPコネクションを張ってIRCサーバと通信している点が若干特徴的かもしれない。 IRCクライアント画面キャプチャサンプル
デプロイ時に実況中継するIRCボット


サンプルコード
#!/usr/bin/ruby

require 'socket'

chan = ARGV[0]
msg  = ARGV[1]

sock = TCPSocket.open("localhost", 6667)
sock.send("NICK DeployBot\r\n", 0);
sock.send("USER DeployBot localhost localhost :DeployBot\r\n", 0);
sock.send(sprintf("JOIN #%s\r\n", chan), 0);
sock.send(sprintf("NOTICE #%s :<-------------- %s -------------->\r\n", chan, msg), 0);
sock.send("QUIT\r\n", 0);
sock.readlines
sock.close

最初はphpで


を使って実装しようと思ったんだけど 実は踏み台サーバでsocket関数が有効になっていなかったので、設定するのが面倒でもうRubyで杜撰に書いちゃおうと思ってRubyで書きましたww
 KLab若手エンジニアブログのフッター