More than 5 years have passed since last update.

LivesenseAdvent Calendar 2014

@masahixixiin

株式会社リブセンス

プログラマーでも知っておきたい運用、障害のお話

Last updated at 2014-12-01Posted at 2014-12-01

概要

はじめに

Livesense Advent Calendar 1日目担当の masahixixi です。
12/1 Calendar を作成するというライフハックです。
社内の驚かれた方すいません。そしてご協力頂いている皆様に心から感謝します。
急すぎるにも程があるなぁというのは私が一番感じています。お許しを。

なにやるの??

早速ネタ作り(現在17時過ぎ)なわけですが、今から何かを検証、構築する時間はどこにもないわけで言い出しっぺの無計画さだけが際立ちます。とんでもないことをやってしまったと今さら実感しているわけですがそんなことも言ってられない。

そんなこんなで考えた結果、私はインフラエンジニアなので運用にまつわる話ならまだ間に合うという結論に至り、運用の話にします。

運用のお話

プログラマー的運用

さて、本題です。プログラマーの皆さんは【運用】という言葉を聞くと何を思い浮かべるでしょうか。

障害対応してる人
監視してくれる人
OS インストールしてくれる人
データセンター行く人

その他色々思い浮かべると思います。確かにインフラっぽいし運用っぽいですね。

では、プログラマーは運用しないのか？してると思います。

テストコード書く
リファクタリングする
バージョン管理する

これは運用を考えた行動ですよね。

テストコード -> 想定通りの実装になっているか
リファクタリング -> ずっと見やすいコードで開発するため
バージョン管理 -> 経緯の明確化

きっとこういった意図ですよね。その他にも、

master ブランチにいきなり push しない
commit ログは細かく書く
テストが通ってないものはデプロイできない仕様

これらも事故を起こさないためであったり、事故が起こっても切り戻しが可能な状態を保つためのものだと思います。もちろんミスがそもそも起こりえない環境作りも大事ですね。(master branch にいきなり push できないようにする等)

プログラマーが知っておくと得するインフラ的運用

では、プログラマーはどこまでインフラの運用を知っていればいいのでしょうか。
理想を言えば「んなもん、全部だよ！全部！」と言う人もいるのでしょうけどそれはあくまで最終着地点なわけでなかなかそうもいかないと思います。

ここからは【完全に個人的な】たぶんプログラマーが知ってると捗ること（最低でも損はしない）をいくつか紹介したいと思います。

自分たちのコードが動いている環境
- クラウド??オンプレ??
- ネットワークの帯域
- サーバの環境全般(apache なのか nginx なのかとか)
- リソース全般(memory, disk, cpu)
監視されている箇所
- 例：死活監視の項目やしきい値

言い出せばキリがないですが、上記2項目を把握していれば以下のことが個人で判断できるようになると思います。

とある障害がコードによるものかインフラ基盤によるものか
- 障害の切り分けスピードが早くなると思います
- （それはインフラの人がやるでしょ？と思われるかもしれませんが、双方出来たほうが素敵。
自分たちのプロダクトの成長スピードとリソース状況は釣合あっているのか
- プロダクトの成長によるリソース枯渇を防げます

単純に1人で判断できる範囲が増えるので当然といえば当然のことですがこんなところかと思います。

障害のお話

ハインリッヒの法則

まず紹介しておきたいのがハインリッヒの法則です。

[ハインリッヒの法則] (http://ja.wikipedia.org/wiki/%E3%83%8F%E3%82%A4%E3%83%B3%E3%83%AA%E3%83%83%E3%83%92%E3%81%AE%E6%B3%95%E5%89%87)

1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在するというものです。

つまりヒヤリハットレベルのものは日常的に誰でも遭遇しているものかと思います。
例えば、

うっかり master branch へ push してしまった
開発環境を間違えて shutdown してしまった
開発環境のデータだしバックアップしていなかった

などなど危うく適応箇所を間違えていると一発アウトのような事例はいくらでもあります。
1つの重大事故の背後にはいくつものヒヤリハットが日常的に潜んでいるという認識を常に持っておきたいですね。

バカにできない手癖編

手癖？一体何の話だ？と思われるかもしれませんが結構これが恐ろしいことを招きます。

ざっくり紹介すると

$ sudo shutdown -h now
$ sudo rm hoge
$ sudo mv hoge
$ sudo service hogehoge restart

この辺りのコマンドは対象を間違えてしまうとサービス停止直結のヤバイコマンドですよね。
全てを自動化しテストも通し、余計なコマンドは叩かせないことが素敵かもしれませんが全てのオペレーションを自動化というのは途方もない作業で実際現場では手動オペレーションを行っていることも事実です。

なので私は以下のことに気をつけています

対象ホストは正しいのか(uname -n)
コマンド入力後、すぐにエンターキーを叩かない(数秒空けて再度確認)
rm, mv コマンドは一度 ls 等で確認しておき ls を rm に置き換えて実行
- history から↑で戻って ls を backspace で削除し rm 入力
- (history を使うなんて。。という派もいるので何とも言い難いですね。あくまで一例です
手順書のある作業はコピペのみ、手入力しない
- コピペで気をつけたいのがコピペミス。改行が含まれていたり
- 一度エディタに貼り付けて改行コードがないことを確認すると吉

運用の心構え

精神論になってしまい恐縮ですが、今までの経験上バカにできないと思っているのでご紹介します。

今日こそミスを起こすかもしれないという緊張感を持つ
- 気が緩んだ時にうっかりポカは起こります
常に一呼吸を意識する
- コマンドを叩く瞬間は特に大事ですね、ミスは間違えた数秒後に気づくものです
1人で解決しようとしない
- ミスを隠そうとするのはご法度です。速やかな情報共有、関係部署への連絡等が復旧を早くします
少しでも不安があるなら確認者をつける
- 初めてで少し心配だな、入念にレビューしたいなと思うことは誰にでもあります。そこは怠けずにきっちり行いたいですね

細かいことはもっとたくさんあると思いますし、個々人で色々お持ちだと思いますが上記4つは私がミスを減らすために普段から気をつけていることです。

3番目、4番目は特に新人、若手が遠慮してしまいがちなので気をつけたいですね。
言う勇気と言える環境作りの双方大切だと思います。

読んでおきたい運用本

これは業務に活かせるなと思った3冊の運用本を紹介して Advent Calendar を締めたいと思います。

最後の本は小説ですけど運用の本だなぁと思ったので載せました。
内容は読んでからのお楽しみということで。

さいごに

実は先日社内で LT をした際に割と好評だったのでその LT の改良版文字起こしとなります。
もっとテクニカルな内容を期待していた人には物足りない、冗長だったかもしれませんがこの内容を初日の投稿とさせてもらいます。

今日作ったカレンダーにも限らず既にほとんどが埋まってしまいました。私の思いつきにお付き合いいただき本当に感謝しています。最後まで盛り上げていきましょー！

(過去にこの手の話を下書きしていた自分を誇りに思いました...
(間に合ってよかった...

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up