トラブル☆しゅーたーず＃05 ～過去からの贈り物～に参加してきましたので、
ここで一人反省会でもしておこうかなと。
 |
| 当日運営側が記録してたと思われるホワイトボード |
概要とか
簡単に言えば障害対応のチーム戦。当日発表されるチームごとに別れ、それぞれ同様の障害対応を行い
最後に報告書・提案書を発表するという感じの内容。
あとは長いからZusaarを見てもらえれば。
当日役割とかチームとか
当日僕はチーム1になりました。そこまで明確な役割分担はなかったですが、主に実際に障害対応と今後の提案内容の考察をメインに行いました。
各ドキュメントなど
チームごとの報告書
当日利用した諸々のドキュメント郡
https://drive.google.com/?usp=chrome_app#folders/0B7MsWgJqBYxacFUxVS0teG9falU自分自身の反省点など
情報・状況の把握の遅れ
実際の障害対応のことを考えると一番痛い反省点。- 実際に障害が発生しているサーバへのアクセス情報。
- お客さんへの連絡方法。
- 現在どこに自分が対応している障害の最新の情報があるのか。
正直チーム内でもこの辺をなかなか把握できずに、逆に「みんなどーやって把握した！？」という状況。
そこで軽くパニクってしまったのがある意味今回最大の失敗点だったかなと。
メールはオワコンとか言ってる人もいるけど、障害対応する身としては
なんだかんだでこういう情報共有方法に関してはメール・MLは非常に有効なんだなと再認識も出来ました。
Chatwark使ってなかったらどうなってたことか。。。
お客さんの声・顔色を見ない対応を行いがちだった
状況把握が遅れたことに加え、このへんも基本的にチームの方にほとんどお願いして、
自分はふわふわした感じでやってしまったのがまずかったかなと。
これに関しては障害対応している段階から変な気持ち悪さは感じました。
というのも、障害対応の際の温度感と先方は一体何を気にしているのか？
という事が全くの未知数となってしまい、一つ一つの判断に迷いが生じてしまったこと。
- サービスが生きているにも関わらず、SSH・Consoleログインができないという理由で電プチリブートすべきかどうか。
- 買い物かごだけ死んでる状態でWeb画面の表示を続行すべきかどうか。 (中途半端に続行すると逆に問い合わせ量がお客さんに及んでしまうのではないか)
など、考え方次第でどちらにも転がりうる状況はもっと早い段階で突っ込んで質問、
それぞれのメリット・リスクを示した上で提案すべきだったかなと。
自分の常識に従ってしまった
ここに関しては言い訳がましくなってしまうけど、普段仕事で触っている環境は事前にどういうミドルウェアの構成になっているかという事をチームで共有しておく習慣があるため
「大体こういう構成になってるはずだよね。」という感覚で障害対応していたという点。
ただ冷静にこのへん考えてみると
ミドルウェアの情報も無ければ過去の作業履歴に絡む一切の情報がなかったわけで、
唯一わかっていた情報は「Web/DBサーバ」「BATCHサーバ」と呼ばれているという事だけ。
この辺はもっと構成や過去の作業内容を疑うべきだったかなと。
実際、
- いずれのサーバももらっていたログインパスワードはUnixユーザーではなく秘密鍵のものだった おかげでSSHが死んでしまってConsoleログインを試みてもログインできずに非常に焦った。
- サーバ再起動時Apacheが起動していたため、実際はNginxで起動する環境なのにApacheで構成されているものだと信じて疑わなかった ここはlogrotateされていない段階で何かおかしいと疑うべきだった。。
- ミドルウェアのバージョン確認を行わなかった 動いていたApacheが脆弱性を抱えたバージョン(Apache-Killer対策前)の存在に気づけなかった。
- 過去からの贈り物。atコマンドによる強制再起動 対応中に思いっきりパニックのどん底に突き落とされた気分だった。。
実際、このWeb/DBサーバにおけるWeb側はNginxで動くようアプリケーションが実装されており、
Apacheで動かしてしまうと見かけ上正常にサービス提供ができているかと思いきや、
買い物カゴでコケるという致命的な状態になってしまっていた。
しかもApache-Killerも食らっていたことに気づけなかった
(ここはアタックが来た時間、うちのチームはLBでSorryページに飛ばしてたからある意味必然ではあるのだが、、)
元の情報がそもそもないわけだから、ここに関しては今後確認することを肝に銘じよう。
正直ここはネタばらしされるまで全く持って気づくことができなかったし、そもそもatコマンドというものを初めて知った。
などなど、今の会社での業務の常識を180度どころか540度はひっくり返されたような感じがすることが続出。
対応時は「トラしゅだからここまで仕込んできてるのかーーーー！くそーーーー！！」という感覚でしたが
最後の馬場さん(@netmarkjp)からのお話で「いずれも実際に運営が体験したことのある障害の再現」と聞き、
ここも冷静に考えなおしてみると、Nginxの例なんかは
「さいきんNginxとか流行ってるじゃないスカ〜〜？だったらApacheなんて古いのやめて移行しちゃいましょうよー」 「やべー、俺Nginxへの移行やっちゃったし更に安定した可動になるんじゃないスカ〜〜 マジ俺すげーー、かっけーー」 (Apache削除作業忘れ、chkconfig httpd on のまま放置。ドキュメントも特に残さず)
と本当に山○くんがやったのかは知りませんが、
あまり運用にウェイトを置いていないようなところでは普通に起こりうることなのかなという事は感じました。
馬場さんからお話あった。
強制リブートが発生したサーバに関しては
chkconfig --list
cat /etc/rc.local
ls /usr/local/
## 以下自分で気にしたほうがいいと思った点
ls /opt/
ls /etc/rc{1..5}.d/
の確認は最低ライン本当に必要ですね。その他
- 一番最初にChatwarkをチームで提案できたのはよかった。あとでメンバーのTwitterアカウント情報交換するのにも役立った。
- オペレーション部分でちょっと頭が半分パニクってしまってたが、後半提案内容はある程度落ち着いて考えることはできたかなと。
トラしゅ#5 全体通しての感想
非常に濃い内容で、スリルあり、どんでん返しありで非常に楽しく非常に悔しい勉強会でした。
13:00 - 20:00 という非常に長丁場でしたが本当にあっという間でした。
個人的には参加者同士でチームを組む方式が非常に良いですね。
いろいろな経験の持つ方とアツい障害対応を行うことで、普段とは違う視点からのアプローチを見ることができたり、
障害対応に対して持たれている印象を自分の目で見て耳で聞くことができたりと
親睦を深めながら進められるのが良いですね。
また今回のタイプの障害対応をしてみて、
「今起こっている問題にどういう形で落とし所をつけるのか？」という事が大事であり
障害を技術的に解決するではないという事は改めて肝に銘じようと思いました。
ex.
アクセス増える時間がわかってるならその時間に張り付いてApache再起動を繰り返して過ごしたってダウンタイムは減らせる(by @netmarkjpさん)など
そのためにはお客さん、そして対応を行うエンジニアチームと普段からシステムに関する認識を合わせておくのは本当に必須だなと。
障害のネタばらしをされた際や他のチームの発表・対応内容をみて「できることはまだあったんじゃないか？」
というなんとも言えない悔しさがこみ上げてきたので、是非次回も参加してリベンジしたいところです。
次は優勝と言うよりは、状況を把握しつつ、ベストな提案をして問題解決ができるようにしたいですね。