リモートチームでシステム障害に立ち向かう対応フローを作って運用してみた
ソフトウェア開発をやっていると避けては通れないのがシステム障害。 ソフトウェア開発チームは障害を0に限りなく近づけるために頑張っていても、時折起きてしまうのが現実ですよね。 起きてほしくないシステム障害ではありますが、システム障害はチームが強くなる機会だと捉えています。 この記事では、障害対応フローの紹介と説明と、運用してみて良かったことについて紹介していこうと思います。
背景
初めに背景を軽く紹介すると、私がスクラムマスターを務めているプロジェクトで、システム障害の根本対応が本質的解決になっていなかったことが原因で、同じ問題を繰り返してしまったことがありました。これを受けて障害対応フローを再整備して、障害に強くナレッジが溜まりやすい仕組みを作ることに挑戦してみました。 プロジェクトはWebアプリ、API、モバイルアプリがあります。開発チームは以下の5名で構成されています。
エンジニアの技術レベルは高いため、私は障害発生時にファシリテーターとして振る舞うようにしています。
また、タイトルにもある通り、このチームはリモートで構成されていて、メンバーは日本各地バラバラに点在しています。 そのため、Slack や Google Hangout などのツールを駆使して一緒に働いています。 リモートならではの困り事もありますが、リモートだろうがオフィスだろうが大筋はそれほど変わりないと思います。
それでは、実際の対応フローを時系列に沿って紹介していきます。
【認知】障害発生！戦いの始まり
発生してしまいました。システムトラブル。 スクラムマスターは即座に Slack で障害が発生した旨を通知して、 Google Hangout に開発メンバーを招集します。
落ち込んでいる人もいれば、慌てている人もいるかもしれません。 一呼吸置いてから、明るいトーンで「お疲れ様です！」と挨拶をして始めましょう。
スクラムマスターは以下の障害対応フローテンプレートをコピペした issue を起票し、チームみんなでこれを見ながら対応に当たります。 ここまで終わったら認知フェーズは完了です。
# 認知
- [ ] Slack の #general に @channel で事故が発生している旨をアナウンス（実施者: 事故に気付いた人）
- [ ] スクラムマスターは障害対応チケットを起票（実施者: スクラムマスター）
- [ ] DS 部屋に集合（対象: 開発メンバー）
# 判断
- [ ] 問題の階層の認識を合わせながら、対応の方針を検討（以下のフォーマットに沿って原因分析すること）
事象: 何が起こっているのかを正確に把握する
問題: それによって誰がどう困るのかを確認する
原因: なぜそれが発生してしまうのかを検討する
解決策: 以上を踏まえてどういった施策を行うか決定する
- [ ] チェックポイントの確認
- [ ] [事象] みんなの目で確かに確認しましたか？ 再現しない問題に対処するのは鳩に豆鉄砲です。
- [ ] [問題] それは本当に対処しなければならない問題ですか？ 実は誰も困らないかも？
- [ ] [原因] 原因は確かですか？ 仮説に過ぎないなら検証してから次に進みましょう。
- [ ] [解決策] 問題の先送りになっていませんか？ 怪しいようならもっと根本的な原因から考え直しましょう。
- [ ] 事象・問題・原因・解決策を障害対応issueにコメントとして投稿する
- [ ] 解決策に対してチーム内で合意形成する
# 操作
- [ ] 対応コードを書く
- [ ] 対応コードのレビューを行う（コンソール操作は画面共有で確認しながら実施する）
- [ ] リリースチケットを発行する
-> 以降はリリースフローに準拠して作業を実施する。
【判断】認識を合わせながら必要十分な戦略を
『怪しそうなところを速攻修正して hotfix ！』 これは危ないパターンです。ついつい解決策に走りたくなるのは自然なことだと思います。 しかし、はやる気持ちを抑えて事象・問題・原因・解決策の順に、メンバーで認識を合わせながら障害対応を進めていきます。
事象: 何が起こっているのかを正確に把握する
いわゆる再現確認です。 再現確認は自分の手を動かし、自分の目で確認するのが一番です。 機種依存や環境依存など、みんなの手元で再現できない場合は、再現できる人の画面共有をしてみんなで確認するようにします。
なかなか再現しないと『レアケース』ということで優先度を下げたくなってきます。 しかし、開発者からすればたくさんの利用者のうちの1人かもしれませんが、障害の影響を受けた利用者にとっては目の前で起こっていることがユーザー体験の全てです。 場合によっては困っている人にヒヤリングをしたり、そばで見せてもらったりして、なんとか手がかりを探していきましょう。
問題: それによって誰がどう困るのかを確認する
再現確認ができたら、一体何が問題なのか確認します。
「◯◯機能の利用中にアプリが先に進まない」というように、システムをベースに考えるのではなく、 「◯◯したいユーザーが△△することができない。」というように、どんな利用者がどんな時に困るのかを整理します。
こうすることによって、問題のクリティカル度をよりユーザー視点で判断することができます。 場合によってはただの操作ミスであって対応の必要がないこともあります。（利用者の操作ミスを誘発してしまうシステムにも改善の余地があります。しかし、「やらなくてはならないタスク」ではなく、「やった方が良いタスク」なので、チームで定められた場所に起票しておきましょう。）
原因: なぜそれが発生してしまうのかを検討する
続いては問題の原因を特定していきます。 ここでは目の前で起きている事象の原因を探っていきます。 事象と問題の認識が揃っていると、メンバーから「◯◯が原因ではないか？」といった仮説が上がってきます。 ここで上がったものは『仮説』に過ぎません。検証されて始めて『原因』になります。 検証すると、空振りに終わるパターンは意外と多くあります。 原因さえしっかりと特定したら、あと一息です！
解決策: 以上を踏まえてどういった施策を行うか決定する
原因さえ特定されれば、解決策は色々と出てくるはずです。 あくまで障害対応なので、スピーディーに対応できる必要十分な解決策を選択していきましょう。
【操作】いよいよシステムに執刀！
ついにシステムに手を入れていきます。 事象・問題・原因・解決策の認識があっていれば、やることは明確になっているはずです。 システムに手を入れる時も、必ず複数人で対応に当たるようにします。 ソースコードに手を入れる場合は画面共有をしながらペアプロをしたりコードレビューを行うようにします。 コンソールで作業をする時は、画面共有をしながら互いに確認しながら操作を行っていきます。
一次対応完了！ ナレッジ共有や根本対応のための振り返り
一次対応お疲れさまでした。 ここからはもう一度、障害の内容の振り返りをするのと、根本対応について話し合っていきます。 振り返りは以下のテンプレートに沿って行っています。 開発チーム以外への情報共有にも使えるので、丁寧に書いていきましょう。
## 事象 - ○○が□□になった ## 経緯 - yyyy/mm/dd HH:MM: ○○発生 - yyyy/mm/dd HH:MM: □□に連絡 ## 影響範囲 - ◯◯なユーザーが△△を利用できなくなった ## 原因 - ○○が□□だったため ## 一次対応 - □□を△△に変更 ## 根本原因 - ○○を確認するしくみが無かった ## 根本対応 - ○○しなくていいようにする
一次対応で事象・問題・原因・解決策についてしっかりと話し合っておくと、 最後の根本原因や根本対応のディスカッションが驚くほどスムーズに進みます。 ここの根本原因こそが『チームの弱み』であるため、根本対応を行うことこそが『チームを強くすること』だと私は考えています。
導入してみてのチームの変化
このフローを３ヶ月ほどチームで運用してみました。 運用してみて良かったこととして、元の課題であった障害の対応不良を防げるようになった他にも2つチームに変化があったように感じます。
1つ目は、障害対応の時間がワイワイと楽しくなり（こう書くと不謹慎に見えますが・・・）、かつ、対応時間が短くなりました。 強敵なボスに作戦を立てながらパーティーで立ち向かうような感覚です。少数の人が頭を抱えて対応するよりも良いことだと思います。
2つ目は、チームの障害に対する意識が高まりました。私達のチームでは2ヶ月ごとにチーム及び個人の目標設定をしているのですが、障害の根本対応に関連する目標を掲げるメンバーがいたりするなど、メンバーの行動にも変化が現れているように感じます。
まとめ
この記事では私たちのチームの障害対応フローの紹介と、フローを導入してのチームの変化について紹介しました。 障害は無いに越したことは無いですが、今後も発生してしまった時は強いチームを作る好機として捉えて行きたいと思います。
Google Home と2ヶ月間暮らして良かった試みと悪かった試み
2017年の年末に Google Home を購入して以来、約2ヶ月いろいろな活用方法を試してみました。生活が便利になって使い続けているものもあれば、微妙ですぐに使うのを辞めてしまった試みもあります。この記事では試した内容と、良かった度合いを5段階評価で紹介していきます。 紹介する活用例は IFTTT を使ったり、 Google Apps Script を書いたりすることが必要なものもあります。その辺の技術的な情報は気が向いたら Qiita に書いていこうと思います。
仕事効率化系
私はオフィスの無いフルリモートワークの会社で働いているため、自宅のワークスペースで仕事をしています。Google Home はワークスペースの机の上に設置しており、家で仕事をしている時はいつでも Google Home を使用することができる環境です。
仕事ログの可視化 評価:2
私は以前から仕事において何にどのくらい時間を使ったか、可視化するようにしていました。 もう少し具体的に書くと、1日のスタートに今日やることとそれぞれにかかる時間を見積もり、終了後に振り返りをするようにしています。ノートで手書きで管理したり、Google Calendar やレスキュータイムなどのタイムレコードアプリを使ったり、いろいろと試してみましたが、いちいち実績を記録するのを面倒に感じていたので、スマートスピーカーに管理してもらうようにしてみました。
利用方法は簡単で、仕事を始める時に「OK Google, これから◯◯を開始」と言うだけです。 これだけで、何時に何の仕事を始めたのかが Google Spreadsheet に記録され、1日の仕事を終えたタイミングで以下のように1日の時間の使い方をグラフで表示してくれます。
運用開始した時はなかなかイケてる気がしましたが、3日くらいで辞めてしまいました。 入力するのが面倒だったり、入れ忘れると正確に計測できなかったり、予実比較がしにくかったり、他のタイムレコードツールで直面したものと、全く同じ問題が起きました。結局のところ入力インタフェースの問題ではないのだと思います。
勤怠管理マネージャー 評価: 3
仕事ログの可視化に近いのですが、会社の勤怠管理を Google Home に任せてみました。
このように Google Home に喋りかけると、Slack で他の社員にも勤怠をお知らせしてくれます。
現状の問題点としては、会社で利用しているクラウド HR システムと連携していないため、結局は手動で入力しなければならないことです・・・。Slack に出社・休憩・戻り・落ちますとメモを残しておくのと変わらないですね。とはいえ、都度 Slack に打ち込むより楽なので結構気に入っています。 今年に入ってクラウド HR システムの API が公開されたようなので、連携部を実装していこうと思います。
読書メモ 評価: 1
本を読んでいる最中に、「ここは大事だ！」と思った時にメモに残しておきたいことがあります。 これまではスマホを開いてノートアプリに入力していましたが、本を読む動作とスマホを切り替える操作が面倒くさい・・・。そんな問題を解決したくて始めた試みです。 メモを残したい時に「OK Google, 読書メモ、◯◯◯◯◯◯◯◯◯◯◯◯◯◯(メモの内容)」と話しかけると、Evernote にメモしたフレーズが記録されるというシンプルなしくみです。
運用開始後、1時間で使うのを辞めました。 イマイチな理由は2つあります。
1つめは、文字数制限が厳しいことです。 25文字くらいが限界なようで、少し長い文言を喋りかけると Google Home が「すみません。よくわかりません。」と返してくれます。更に要約されることを強要されたり、繰り返し言わなければならないのが物凄いストレスでした。
2つめは、変換の精度がよくないことです。 運動について調べ物をしていた際に、 「体を動かすことによって疲労を取り除くこと」というメモを残したら、 「体 を 動かす こと によって 給料 を 取り除く こと」と記録されました。 給料を取り除かないでくれー！！ また、半角スペースが途中に含まれてしまうので、テキストを再利用するにも一手間加えなければなりません。
Google Home による読書メモ自体は最悪のユーザー体験だったのですが、思わぬ副産物もありました。 それは、 iPhone の音声入力がとても優秀なことに気付いたことです。 今までそれほど音声入力を使っていませんでしたが、慣れればキーボードより早いので今後積極的に活用して行こうと思います。
おうちハック系
続いては、Google Home のおうち利用編です。 我が家の Google Home はワークスペースに1つあるのみですが、リビングルームからでも問題なく動作してくれます。
電気の ON / OFF 評価: 5
Google Home と家の電灯を連携してみました。 家の電灯はスマートホームに対応しているものではないため、IRKit を使って連携させています。
「OK Google, 電気をつけて」で点灯。 「OK Google, 電気を消して」で消灯。
といったシンプルな操作です。 至ってシンプルなのですが、やっぱりシンプルが一番。 完全に家族の生活に溶け込んでいます。 電灯のリモコンが見つからなくて困ることも無くなりとても快適です。 少し未来の家は音声で電灯を制御するのが当たり前になるのではないかと思います。
ルンバの掃除命令 評価: 2
「OK Google, ルンバを使って掃除を開始して。」と喋りかけるとルンバが掃除を開始してくれる、Google Home の標準機能です。 最初は喋りかけた時に掃除を始めてくれて「すごい！」と思いましたが、実際の所それほど便利ではありません。そして、ボタンを押すのと同様にルンバの起動を忘れてしまう問題が発生します。 結局のところ、ルンバはスケジュール起動させることにしました。時々イレギュラーなミーティング中に「ててーててーー♪」とルンバの起動音が鳴ってしまいますが、すぐに止めれば良いだけなので、全く困っていません。
よく使っているデフォルト機能
ここまでは少し応用的な Google Home の活用方法を紹介しましたが、基本機能でよく使っているものも紹介しておきます。
まずは、目覚まし機能です。「OK Google, あした 8 時に起こして」と言うとアラームをセットしてくれます。少し前までは、アラームを止める際の反応がすこぶる悪くてストレスフルだったのですが、改善されてとても使いやすくなりました。
次は、定番ですが天気機能です。特によく使うのは「OK Google, 今の気温は？」です。「◯℃です。」と即答してくれます。天気は窓の外を見ればわかりますが、気温まではわからないので、Google Home に気温を訪ねてから着る服を選ぶようにしています。
最後に、音楽再生です。 Google Play Music をトライアル契約していますが、「ちょっと BGM が欲しい」くらいの時にとても便利です。私の場合、それほど曲目にこだわりが無いので、いい意味で適当に流してくれるのはとてもありがたいです。
スマートスピーカーへの感想
以上、スマートスピーカーと2ヶ月間暮らして良かった試みと悪かった試みを紹介しました。 スマートスピーカーを使っていて一番驚いた点が、ITゴリゴリでない家族からのウケがとても良いことです。 普段はガジェットを買うと「また意味分からないもん買って〜」みたいな扱いで、家族が使うことはあまり無いのですが、スマートスピーカーは家族にも受け入れられ、使われています。 会社で開催されたスマートスピーカー座談会でも、所帯持ちの家庭の方がスマートスピーカーを活用している意見が多く出ていたので、私の家庭に限った話では無いようです。 今後、スマートスピーカーがどのように私達の暮らしを変化させていくのか楽しみですね。
