インフラエンジニアとして普段心がけていること

1. インフラエンジニアとして普段心がけていること
湖山 翔平/Shohei Koyama
@sion_cojp

2. 自己紹介
湖山 翔平 / @sion_cojp
27歳
元FPSプロゲーマーでアジアチャンピオン
qiitaをよく書いてます
http://qiita.com/sion_cojp
インフラエンジニア（この資料書いてた頃はインフラエンジニアだったんです。。）
11月からWebアプリケーションエンジニア
株式会社リブセンス（２年目）

3. 周りの方々の、立ち回り方や考え方（もちろん技術も）
をどんどん組み込んで日々努力中。
でも
「どう振舞ってるか？普段意識してることやコツは？」
という話を外部の方に、あまり聞いたことがないな
と思いました
この記事を書こうとした理由

4. なので今回は自分がリブセンスで、
一人のインフラエンジニアとして、
インフラ周りで意識してることをお話します。

5. リブセンスでは色んなメディアがあります
インフラは各メディアに担当者（窓口役）が
一人います
障害対応は、手が空いてる人が対応
基本はオンプレ。AWSなどパブリッククラウドもあります
まずどんなところで働いてるの？

6. ここから本題

7. 最初は手打ちをしたほうがコマンドを覚えることが出来、
障害対応の際に役立ちます
またコマンドの理解にもつながります
ただしルール上、絶対にコピペじゃないとダメな部分はあるので
そこはコピペしてます
私はあらかじめチームに「なるべく手打ちしたい」と話しを
通しています
新しく入った方にも
「覚える為なら危険な作業以外は手打ちでもいいよ∼」と
こっそり誘導
1. 初めてみる手順はコピペをせず、手で打ち込む

8. 障害対応は、知らないことを知るチャンスが多いです
また基礎知識の復習にもなります
もし自分が対応したことある障害の場合は、
未経験の人に優しく教えてます
ただし、サービスを迅速に復旧することが一番大切なので、
そこはうまく判断してます
2. 障害対応は積極的に参加。迅速に解決

9. 癖が付くまで時間かかりますが大事。
障害やインストール後の挙動。
今どう動いてるかが全てです。
古い手順書を鵜呑みにして・・・ってことは良くありますね。。
そんなときはログを見れば一発です！
それでも分からなかったり、自信がなければ
ソースコードを読んで誰かに確認してます
3. 困ったらログを見よう

10. 私は具体性のない、紛らわしい発言はテンパったりするので、控えてます
特に疑問文はなるべく避けて、指示形式にしますね
「それダメなんじゃない？」
（何がダメなの・・・）
「それここが影響するかもしれないから、この部分確認したほうがいいよ」
（分かりました！）
自分は①②③とか、番号をつけて報告してます
理由は
「①だとこういう部分が問題になるから、②の方針でいきましょう」
的な会話が出来、スムーズになりやすいからです
あとは分かりやすく、簡潔に。
あと皆さん忙しいと思うし、
部長さんやリーダーさんがパパッと判断出来るように優しさを持ちましょう
4. 障害対応中の報連相は明確に
NG
OK

11. 対応中の報告例
例

12. 5. 障害対応後の報告は時系列も入れる
「どのくらいの時間障害があったか」
「何時にどう対応したか」
っていうのは、後々サービス影響してたりするので
時系列に沿って報告するのがベストです
時系列が多い場合、①②③の番号を振ったりしてます
開発者に報告するのは、簡潔に。
インフラ内での報告は具体的（打ったコマンドの記録）にしてます
（開発者の中で、細かい内容が知りたい人がいれば、インフラ内の報告を見せれば良いです）
例

13. インフラが全体告知して何か作業、と聞くと
「ひょっとしてサービス断発生！？」って思う人もいるでしょう
主なポイントは、
「作業でどうサービスに影響するか」
「情報共有なのか、我々に何かやって欲しいのか」
目的を明確にするように心がけてます
6. 開発者に依頼するときは不信感を与えないようにする

14. 情報共有例
例
例

15. インフラ要因の可能性もあるので
すぐ調べて、「インフラ要因かどうか」の回答をしてます
よくを言えば、開発アプリのリポジトリのソースコードを
軽く読んで、「ここらへんじゃないですか？」
と答えられると完璧
「この人に聞けばなんとかなる」という信頼が得られるのは
良いこと。
ですが、質問責めにあって自身が持ってるタスクが進まない方は、
「インフラで困った時の回答ページ」を用意し、
よく聞かれるFAQを書いてます
7. 開発者が困ってたらすぐ助ける

16. 困った時の質問ページ例
例
1項目3行以上かかないようにしてます

17. どの作業でも自動化出来ないか考えてます
infrastructure as code の思想は常に心に。
8. 作業が自動化出来ないか考える

18. チャットで「！」「っ」を付けるだけで楽しそう
「分かりました。」って言うより、
「分かりましたっ！」って言うほうがポジティブそう
雰囲気も良くなるし、楽しく仕事出来るし、
結構大事だと思って心がけてます
9. 楽しく仕事する、ポジティブに会話する

19. 1. 初めてみる手順はコピペをせず、手で打ち込む
2. 障害対応は積極的に参加。迅速に解決
3. 困ったらログを見よう
4. 障害対応中の報連相は明確に
5. 障害対応後の報告は時系列も入れる
6. 開発者に依頼するときは不信感を与えないようにする
7. 開発者が困ってたらすぐ助ける
8. 作業が自動化出来ないか考える
9. 楽しく仕事する、ポジティブに会話する
まとめ

20. 以上となります。
皆さんも心がけてることがあれば、
是非書いてみてください！