SIerにいる若手開発者（プログラマ）が知るべき運用とは その２
以下の記事の続きです。
SIerにいる若手開発者（プログラマ）が知るべき運用とは その１ - のんびりプログラムのお勉強でも・・・・・・・
前回で以下を意識してコード書こう！でしめました。 今回は具体的に何が必要なの？を書こうと思います。
- いつ何が起こったか情報も何もなく、意味不明で何をしていいのかわからない非定型作業
- いつ何が起こったかだけはわかるが、意味不明で何をしていいのかわからない非定型作業
- 非定型ではあるが必要な情報はそろっており、頑張ればなんとかなる非定型作業
- 手順が整備されていない定型作業
- 手順が整備されている定型作業
- 何もしない
「いつ何が起こったか情報も何もなく、意味不明で何をしていいのかわからない非定型作業」から「いつ何が起こったかだけはわかるが、意味不明で何をしていいのかわからない非定型作業」へ
「いつ何が起こったか情報も何もなく」→「いつ何が起こったかだけはわかる」が変わっています。 ポイントは「いつ」と「何が起こった」です。 今回のメインテーマ。
「いつ」がわかるようにする
簡単にいうと何か起こったらすぐ運用者がわかるようにする！です。システム側から教えてあげないと運用者は気付くことができません。 つまり、先ほど書いた「監視」もしくは「人間が普段のコミュニケーションに使うツール」を使って教えてあげる必要があります。 プログラムレベルでいうと以下を気を付ける必要があります。
- 想定外の例外などが発生した場合、必ず監視にかかるようにしておく必要があります
- e.printStackTrace()やSystem.out(“エラー発生”)とかやっていると標準出力に出力されてしまう場合があります。Javaだと多くはloggerを使用することが多いです。そのloggerが出力したログを監視して運用者に伝えます。
- そのうちITが進歩すればなんでも自動化できるようになるのでしょうが、限界があります。またお金の問題もあります。ごくまれに発生する事象に残念ながら高機能を作ることができません。その場合には運用者に「あとはがんばれ！」を伝えておくことも必要になります。
- 多重障害に対する対応を自動化することは難しくこのパターンに入れておくとよいです。
5W1Hを明確にする
次は「何が起こった」です。 「いつ何が起こった」を明確にするため、5W1H（When、Where、Who、What、Why、How）を運用者がわかるようにします。 若干の拡大解釈しつつ、注意点を書きます。 「いつ」がわかった前提のため、ログにどんな情報を出すべきかが中心になります。 下記に例を書きますが、エラーのプログラムをする場合に5W1Hを意識してほしいです！
When
いつ！ 上で書いた「いつ」と重なりますが、ここでいうのはログの時間です。多くの場合は単純に時間を出せばいいのですが、注意点は以下。
- サーバが違う場合、時刻は同期がとれているのか？
- サマータイムや国が違う場合の時差は考慮されているのか？
必要に応じて、ただサーバの時刻を出すのではなく、DBサーバなどから時刻を取得してすべてのサーバで出すなど工夫すると良いです。
Where
どこで！ いろいろあるのですが、ソース部分のどこで起きたよ！を教えてあげる必要があります。 Javaなら例外発生時はStackTrace出せばわかります。 あとは自分でエラーにする場合。エラーログを出して終わりにしてしまったりするのをよく見ますが、IDを出したり どこでエラーを出したかを明確化するとより分かりやすくなります。
Who
誰が WEB APなどの場合、ユーザ情報を出力してあげると誰なのかわかります。BtoCの場合は難しいですが、社内システムなどの場合は、該当のユーザに連絡を取って謝ったりもできますｗ
What
何を。 これが考慮されていないログが非常に多いと個人的には思っています。 入力されたデータなどをわかるようにします。プログラムのバグの場合、特定のデータが来ると処理に失敗する場合があります。 その際に「エラーが出た！」だけ言われても解析することができません。 処理しようとしたデータがわかるような情報を出力することで原因解析が早くなります。 あと、例えば文字列の処理に失敗した場合にこの文字の処理に失敗したよ！というログを出しているプログラムを見かけますが、 これは「What」に答えられていない場合があります。 該当の文字はそれはそれでいいのですが、処理中のレコードのpkeyだったり、その他に紐づけられないとその文字でエラーになったのは わかりますが、どこから混入したのか追えなくなるので注意が必要です。
Why
なぜ？ このエラーはどんな場合出得るのかを教えてあげます。 「エラーが出た！」だけでなく、このエラーが出た場合はDBとの接続に失敗しているから～を見てね、などです。
How
どうやって。 何をしようとしていたのか、わかるようにしておくことで原因解析が早くなります。 5W1Hだぜ！っていったけどHowって難しいｗ
「いつ何が起こったかだけはわかるが、意味不明で何をしていいのかわからない非定型作業」から「非定型ではあるが必要な情報はそろっており、頑張ればなんとかなる非定型作業」へ
1個上のいつを教えて5W1Hを伝えれば、運用者は調べることはできるようになります。 さらに1歩踏み込んで「何をしていいのかわからない」から「頑張ればなんとかなる」にします。 これはソースの書き方というより運用者が調べられるようにすることです。
主にはドキュメント。1つは設計書をきれいに書きましょう！ってことです。 さらに言うとこういうエラーの時にはこれを見てね！というのがあるとなおよいです。
意図しないエラーで発生頻度が低いものはここまで持ってくるのが限度だと思います。
「非定型ではあるが必要な情報はそろっており、頑張ればなんとかなる非定型作業」から「手順が整備されていない定型作業」へ
どんなエラーが発生するのか運用側に伝えてあげます。 エラー一覧みたいなやつですね。この状態だとエラー内容が頭に入っていたりして、 エラー見た瞬間にまたいつものか！みたいなやつです。
影響がないのはいいですが、オオカミ少年みたいになってしまうので、この状態で事象をとどめるのはやめて さっさと直すか次の段階までは進めてください。 ただ現場行くと意外とこの状態でとどまっている事象が多いです。 ずっとプロジェクトにいる仙人みたいな人が直したり、影響ないよ！って言ったりしているパターンです。
運用は人に依存するのは排除すべき！
「手順が整備されていない定型作業」から「手順が整備されている定型作業」
エラーなど運用作業に対して手順書を作成します。 シェルなどを作ってあげてでなるべく手順を簡略化するとさらによいです。
よく見かけるのがメモみたいな手順書ですが、最初はそれでもいいですが、 誰がやってもできる手順書を心がけるとよいです。
またエラー出なくても手作業が必要な場合はここまで落としてあげる必要があるため、 5W1Hなどを意識して運用者に情報を伝えつつ、手順書まで作成して誰でもできるようにする必要があります。
何もしない
手順書が作れるくらいだったらプログラマならそもそも自動化しろって話です。無理なのも多いですがｗ
まとめ
2回にわたってプログラマに知ってほしい運用を書いてみました。 私自身も若い頃は運用ってよくわからず、とりあえずリリース後に頑張ってくれる人たちだ！ってことで、 ほぼ故障みたいなやつを先延ばしして運用で頑張る！みたいにしてしまったことがあります。
実際には運用の方が期間が長くて、人も多く携わるし、お金もかかります。 これ誰かが対応するんだな～だったらこうしておこう！みたいな感覚を持ってプログラミングするだけでも だいぶ違うと思います！
SIerにいる若手開発者（プログラマ）が知るべき運用とは その１
最初に
今会社で実業務しつつ、新人研修をやっていたりするのですが、 プログラムを書くのはJava研修的なものでやってきているけど、例外catchしてprintStacktraceとか 書いているのはいいけど、なんで書いているのか、実業務でどう使われる？とか いろいろ足りていない、、、というか知るわけないのでちょっとここでまとめて 教えようと思います。
私の経験で見てきたこと中心なので、間違っているとかあると思いますので、 もし何かあればコメントいただけたら幸いです。
システム運用とは？
システム運用って何でしょうか？？開発系の部署と運用系の部署があって・・・は聞いているかも？ で、私がやっているのは開発系であり、運用なんて関係ないよねー あ、ここでいう運用はシステム運用の事です。
って、そんなことないです。
システムの一連の流れとしては、開発してリリースすると運用が始まります。 ほとんどのシステムは開発より運用の方が長いです。 そして開発時にいろいろ運用を意識していないと後々運用側が困ったり余計なコストがかかったり 下手するとシステムを直す必要まで出てきてしまいます。
ってちょっと横道に行った。運用とは？ですが wikipedia見たらこんな感じでした。 「システム運用（-うんよう）とは、コンピュータシステム等のシステムが停止することなく、利用顧客に対してつつがなくサービスを提供できるよう当該環境を維持管理すること。」
「つつがなくサービスを提供」するためには何をする必要があるのか？
大きく言うと2つに分かれます。
- 定型作業
- 非定型作業
ここでは大きく「定型作業」とはある流れに従った作業とします。非定型はその逆で流れがない、つまりマニュアルなどが作れるかどうか？です。 システム運用は「定型作業」と「非定型作業」を毎日行って「つつがなくサービスを提供」しています。
定型作業
じゃあ定型作業ってどんなものがあるのか？例えばこんなものです。
- システムからある申請が出された場合に、その内容を印刷して郵送する
- 月に1回システムの利用状況を資料に取りまとめてみんなに共有する
- 手順書に従い、サーバに入ってコマンドを実行する
などなど。 基本的には手順教えてもらえれば誰でもできる、さらに発生日時が決まっていることが多いです。
非定型作業
こちらはマニュアルなど存在せず、エンジニアなどが考えて対処する必要があります。例えば
- WEBのシステムがさっきまで使えていたのに画面が全くでなくなったのでなんとかしなくてはならない
- 処理の合計金額がおかしくなっておりお客さんからクレームが来た
などなど。 手順などなく基本的に想定外で、いつ起こるかわかりません。胃が痛くなりそう・・・(笑)
システム運用の理想形
運用者の目線からすると理想はこれです。
何もしていないけどつつがなくサービスを提供されている
これが最強ｗ ただこれを実現するためには、 サーバなどは絶対に落ちることはなく、書いたプログラムは絶対にバグはなく、 ユーザがやりたいことはすべてシステム化できている必要があります。
無理ｗ
なので、そんな非現実的な理想はともかくですが、 運用者としたらやりたくない作業は以下の順番になります。 細かく区切ればいくらでもあげられそうですが、いったん下記と定義します。 つまり開発者は作成したシステムで発生する事象がなるべく下記で下の方に近づくことを目指せば 運用者から感謝されます。
- いつ何が起こったか情報も何もなく、意味不明で何をしていいのかわからない非定型作業
- いつ何が起こったかだけはわかるが、意味不明で何をしていいのかわからない非定型作業
- 非定型ではあるが必要な情報はそろっており、頑張ればなんとかなる非定型作業
- 手順が整備されていない定型作業
- 手順が整備されている定型作業
- 何もしない
システムが運用者に情報を伝える手段
いったん目線の角度を変えますが、システムが運用者に情報を伝える手段はざっくり以下になります。
- ログ
- 監視
- メール/電話/チャットなど人間が普段コミュニケーションに使うツール
※１ 監視にかかってメールじゃん！とかはいったん気にしないでｗ ※２ 電話とかチャットとかもありますが、SIerで自動電話とかなかなか使えないのでいったん忘れて。
ログ
これはあまり説明いらない気もしますが、多くの場合は単純にファイルにログの情報を出します。DBなどの場合もあります。 運用としては運用者が見てみるか！と思ったら見ることができます。 基本的にログが能動的に運用者に何か起きたよ！とトリガーを引いてくれることはありません。
監視
そのままですが、システムの状態を監視して想定外の状態になった場合は特定のアクションを実行します。 JP1やHinemosがその代表で世の中にはたくさんのミドルウェアがあります。 メジャーどころの監視としては以下のような監視です。
- CPUやメモリ、ディスクなどにちゃんと余裕があるかどうかを監視
- プロセス（Tomcatなど）がちゃんとあがっているかどうかを監視
- ログに特定の文言が出てこないかどうか監視
- HTTPのステータスや電文の中身が正常であるかどうか監視
特定のアクションとしては、単純に監視ソフトウェア上で赤文字で出したり、「人間が普段のコミュニケーションに使うツール（メール/電話/チャットなど）」に通知したり、パトカーみたいなランプを光らせたり何らかで運用者に伝えます。
人間が普段のコミュニケーションに使うツール（メール/電話/チャットなど）
これは上記で書いた監視で想定外の場合、もしくは単純にシステム内の機能として運用者に通知してあげるという機能を作ってあげる必要があります。 プログラムとして以下のようなコードを書くだけ。
if(運用が必要な場合) {
運用者にメールを送信する
}
実際にコードを書く際にどうすべきなのか？
やっと本題ｗ 先ほども書いた以下の順序が下に下がるようなソースを書く必要があります。
- いつ何が起こったか情報も何もなく、意味不明で何をしていいのかわからない非定型作業
- いつ何が起こったかだけはわかるが、意味不明で何をしていいのかわからない非定型作業
- 非定型ではあるが必要な情報はそろっており、頑張ればなんとかなる非定型作業
- 手順が整備されていない定型作業
- 手順が整備されている定型作業
- 何もしない
次の記事に続きます。
どっかー
docker-toolboxとdocker-for-windows
- 会社のPCにはdocker入れてJenkins動かしていたりするのですが、いろいろあって家のWindowsに入れたいので、手順思い出しがてら久々のブログ。
- docker-toolbox使って入れたような気がするけど、docker-for-windowsってのもあるのか。家ではWindows10で会社だとWindows7だからなー。ぐぐってみた感じdocker-for-windowsはWIndows10のデフォルトに存在するVM？を使うのか。docker-toolboxは確かにVirtual Boxが勝手に入っていておぉ！？ってなったな。
- と思ったらdocker-for-windowsのexeを実行したらHomeエディションでは使えないよ！って出たのであきらめてdocker-toolbox。
docker-toolboxインストール
デザインを少し変えてみました
このデザイン、Mistilteinn
Mistilteinn - テーマ ストア - はてなブログ
を使わせてもらっているんですが、なんか真ん中によっててなーと思っていたので、 CSSをさわってみる。
はてなの右上の管理メニューから「デザイン」を選択
デザインの編集メニューが出るので、スパナみたいなボタンを押して、 カスタマイズ。 一番下の「デザインCSS」
ここにCSSを記述すれば反映されるみたい。
と言うことで、使っているCSS（http://hatenablog.com/theme/11696248318755805834.css）を テキストで参照して、下に追記してクラスを上書き。
僕の場合は、widthおよびmarginが変えたかったので、以下を追加。
#container { margin: 50px; } #content { width: 1235px; } #wrapper { width: 920px; }
幅が広がった！および左側のマージンがなくなった！ レスポンシブとかいろいろ思うことはあるが、とりあえず変わったからいいやｗ
ちなみにここにCSS入れると右側にプレビューが出て変更後の状態が見れるので便利。 とは言え、どこ変えるんだ？って感じだったので、 chromeの開発者ツールを使ってみた。
Jenkins おすすめプラグイン ～ジョブのパラメータをまとめ変更～
もう1つ。 同じようなジョブが並んでいる人向け。
以下のプラグインを使うと、パラメータを一気に変えられます。 バージョンをリストボックスで選択させている人で、バージョンアップ時に 1つずつ変えるの大変なんだよなーとかに！
