トラルブ☆しゅーたーずに参加してきました!
ブログを書くまでが、勉強会です!
昨日、トラブル☆しゅーたーず(#トラしゅ #ncstudy #hbstudy #odstudy)という勉強会に参加して来たのでレポートを書きたいと思います。
参加レポ
簡単に説明すると、お題(障害)からチームで復旧させて障害報告書を作成するというもの。
勉強会には何度か参加した事がありますが、このように実際に手を動かす勉強会は初めて参加しました。
という訳で当日は、楽しみ半分、緊張半分という状態(汗)
Twitterとかを見てると、『わざわざ休日に障害対応とかってw』なんて意見もありましたw
会場に到着すると、ルール説明が行われてからドキドキのチーム発表!
私はチーム6に参加する事になりました。
チーム決定後は、すぐに割り当てられた部屋に移動して障害対応スタートとなりました。
どのチームもメンバーとご挨拶をして、五月女商会様の障害復旧を行ったかと思います。
障害対応時間は約2時間(+お客様都合により延長約1時間)というスケジュールでした。
正直途中まで復旧出来ずにタイムアップじゃないかと思いましたが、メンバーに恵まれて無事に復旧!
※本当にギリギリまで最初からまったく状態が変化していなかったのです(汗)
その後は障害報告書を作成し、全員集合してお客様への説明を行いました。
お客様への報告では各チーム謝るのがとても上手!:)普段どれだけ謝ってるのでしょうか?
お菓子も用意して頂いたものの、内容が内容なだけに会場は完全に重苦しい雰囲気でしたw
優勝したチーム2の方、おめでとうございます!
お客様が何を知りたいかが、きちんと考えられている報告書で勉強になりました!
ちなみに私が参加した、チーム6の報告書はこちらになります。
そして解答編はこちらになります。
チームや自分で反省した内容
- 最初にきちんと資料を見て、レギュレーションを把握する
- 資料をまともに見ずにSSHってどのユーザー指定するの?って悩んでましたw
- 作業分担をしっかりして、効率良く作業する
- 作業分担が出来ずにみんなで同じ作業とかをしていたので、効率が悪い部分も
- まとめる人、コマンド実行する人、何時に何があったかを調査する人、報告書を書く事、障害環境の調査をする人
- 何が何時に起きたかなどの情報も調査すべきだった
- 障害が何時に発生して何時に復旧したかとか、お客様は知りたいですよね
- 障害状況の概要図とかを簡単に用意した方が良かった
- お客様がどんな内容か図を使うと把握しやすかったと思う
- 報告書のフォーマットはWord(文書)形式にした方が良かった
- プレゼンテーションで作成したのですが、報告書の場合はWord形式が適切だったかも
- 便利なツールをもう少し使っておけば良かった
- scriptコマンド(作業ログ)
- ディスプレイ(情報共有)
- ホワイトボード(基本情報の記載場所やメモなど)
- 発表時は最初に現在の状況を伝えれば良かった
- 今も障害中なのか、復旧したのかはお客様にとってとても大事なはず
- Sorryページを出せば良かった
- 障害対応のシュミレーションなので、そこまで気を回せば良かった
まとめ
個人的に障害対応は1人や2人で行うケースが多かったので、今回のようにチームで対応するのはとても良い経験になりました!
他の参加者とコミュニケーションが取りやすいというのも、こういう勉強会の良いところですね。
チームに学生さんがいたので、もっともっと協力してやれたら良かったなーと反省中です。
次回参加した時に生かしたいなと思います!
また、個人的に最近はAWSを使う事が多いのですが、やっぱり『元となる技術をしっかりと勉強する事は大事だな』と改めて実感しました。
元となる技術をしっかり知っているからこそ、AWSを導入した時のメリットやデメリットを把握出来るのだと思います。
そして、男性だけの懇親会(@北海道)の横で合コンが開催されているとか、どんな巡り合わせなんでしょうね。
スタッフのみなさま、会場を提供して頂いたニフティさん、毎度のことながらありがとうございます!