こんにちは！
複数の億規模プロジェクトでPLやってるやまさんです！
バグでDB更新間違ってる…やばい…
エンジニアをやってると、開発が終わってリリースした後にトラブルに遭遇することも多いんじゃないでしょうか。
本番環境のトラブルですが、対応にスピードが求められますよね。
ただ、トラブル対処で求めらるのはITスキルだけじゃないんです。
この記事ではトラブル発生から一時的な対処が終わるまでに必要なことを紹介してみたいと思います。
ITスキルは使っているシステムやプログラム言語に依存する部分が多いですが、ITスキル以外のことは応用がきくので身につけておいて損はないですよ！
それにトラブルって、えらい人も出てくることが多いのでアピールチャンスでもあります！（不謹慎…）
この記事を読んで、エンジニアとしてのスキルアップだけでなく、えらい人からの評価をあげるきっかけにしていただければと思います！←
Contents
トラブル対応は一次調査と二次調査に分かれる
トラブルには一次調査と二次調査があります。
違いはこんな感じ。
- トラブルの一次調査
システムアラームやユーザからの連絡などでトラブル発生連絡を受け、エラー内容や影響内容を把握します。そしていったんの暫定的な対処方針を考えて実施します。 - トラブルの二次調査
一次調査の内容からトラブルの根本原因を究明し、恒久的な再発防止策を検討して実施します。
この記事では”トラブルの一次調査”について詳しく解説していきます！
なお、二次調査部分のことも知りたい場合はTwitterなどでボクにリプやDMをください^^
このブログで記事にして紹介したいと思います。
システム障害発生！ えらい人もお客さんもピリピリする一次調査で必要なこと
システムアラートが鳴っとる…
バグが出てユーザからクレームが…
システム障害ではえらい人やお客さん、それに現場のメンバーも含めてピリピリしますよね^^;
ITシステムはお客さんのビジネスに密接に関連しているのでお客さんはシステム障害にとても敏感です。
なので、システム障害の一次調査では次のようなことを冷静、かつ迅速に行っていく必要があります。
- システムでどんな問題がおきているかの把握
- どのような悪影響があるかの把握
- 一時的な対処が可能かの検討と実行
まずはこの3つのシステム障害発生時の対応ポイントの全体像をおさえましょう。
そうすると、（巻き込まれたときに）自分がどの立ち位置に立つべきなのか、またどの立ち位置が不足しているのか分かってきますよ。
では、障害発生時の一次調査でおさえるべき3つのポイントを説明していきますね。
システムでどんな問題がおきているかの把握
当たり前ですが、システム障害時にはまず何がおきているか把握する必要があります。
- オンライン処理が落ちているのか
- バッチ処理が落ちているか
- それとも処理自体は正常に終了しているけども、DBの更新が誤ってるのか
- etc
この障害時に何が起きているかを把握することは一言でいうと”切り分け作業”です。
システム障害時などのシステムトラブル時には”どこに問題があるのか”調査しましょう、とよく言いますよね。
これは逆言うと、”どこまでは問題ないのか”をはっきりさせることでもあります。
問題部分と問題がない部分を切り分けて、発生事象を正確に把握していく作業なんですよね。
なお、一次調査時点は根本的な障害原因究明をする必要はありません。
根本原因の究明は後回しでＯＫです。
”根本的な障害原因究明は後回し”というのは「あの時のレビューが足りてなかったか…」とかの話は後でやろうねってことですよ！
根本原因の完璧に把握するのは後（二次調査）で行うとして、とにかくシステム上で何が発生しているかを把握しましょう。
後回しでOKな理由は優先順位的に、次の「どのような悪影響があるか」を調査してプロジェクトマネージャーやお客さんへ今後の方針を判断する材料を与える必要があるためです。
どのような悪影響があるかの把握
システム上の問題点が把握できたら、次は発生している”システム障害でどのような悪影響があるか”を把握する段階に入ります。
システムの問題点が分かればいいんじゃないの？
実はそうでもないんですよね^^;
システムはお客さんの業務を行う上でなんらかのツールとなります。
なので、次のような思考方法で”悪影響”の内容を把握する必要があります。
- システムのここの処理で不具合がおきてる
- この処理ができてないと、この後続の処理が動かない（間違った結果になる）
- この処理はお客さんの業務でこういう風に使われてるからこの業務がまわらなくなる
こんな感じです^^
自社のえらい人やお客さんがシステム上の問題点を分かれば、すべてを理解してくれるならいいんですが、正直なところ、そんな人めちゃ珍しいです。
悲しいですが、システム障害の内容をそのまま報告して理解してくれるえらい人やお客さんは少ないのがこれが現実です…
なので、システム障害の内容からお客さんやユーザ視点でどんな悪影響があるのかを把握しましょう。
次の段階で「一時的な対処策」を考えるんですが、対処を考えるのに時間がかかりそうなら”考えられる悪影響”をまずえらい人やお客さんへ報告するのがよいかと思います。
人間って、分からないことに対してストレスを感じます。
なので、特に障害時は早めにこまめに情報共有するのがよいでしょう。
システムにもよりますが、”システムの処理結果が間違うバグ”と”システムが停止するバグ”だと、やまさんの経験上、前者の中途半端に動くより後者の停止の方がマシな場合が多いです。
例えば、バッチ処理で中間ファイルを出力して次の処理につなげていく処理群があったとします。その場合、上位の中間ファイルの結果が間違っていると、後続の処理も全部間違った結果になりますよね。
このように中途半端に動かれるより、停止してしまった方がいい場合もあるので設計時点で”停止する基準”はよく考える必要があります。
一時的な対処が可能かの検討と実行
トラブルはしばらく放置してもいいものもあれば、その場しのぎでもいいので対処しなければならない場合もあります。
例えば、夜中に動くバッチ処理が落ちた場合、そのまま放置しておくと、翌朝お客さんがシステムを使えなくないって状況だとマズいですよね^^;
ほぼすべてのシステムではお客さんやユーザに影響が出る事態になるのは避けろ、ということになっているはず。
上の例だと、翌日の夜にもう一度バッチ処理で落ちてもいいので、翌朝には使える状態にしておく必要があります。
ようはその場しのぎでもいいので、なんとかできるのとできないのでは大きく違うってことですね。
なので、一次調査時点で”一時的な対処方法”の検討をしておく必要があります。
システム障害解決に必要な役回り
ここからはやまさんが考えるシステム障害解決のために必要な役回りを紹介してみます。
必要な役回りを知って行動すると、システム障害時に動きがよくなりますよ！（会社からの評価もあがるかも！ｗ）
トラブル対処を視野広く見てみると、次のような役回りをしている人がいるはずです。
- エラーログなど、システムを解析する役
- 解析結果を伝える役
- 今後の方針を判断する役
なお、①～③あるからといって、3人でやっているとは限りません。
複数の人がシステムを解析していたり、解析する役と解析結果を伝える役を1人がやっている場合もあります。
それぞれ解説していきますね。
エラーログなど、システムを解析する役
1つ目の役割”システムを解析する役”はそのままですね^^:
システムを解析してエラーなどのトラブル内容を調査します。
詳しく語る必要はないと思いますが、あえて言うなら、”事実”と”予想”を分けて考えることがこの役割では特に重要になりますね。
例えば、
システムエラーはDB書込みのとこで発生してるな（←事実情報）
なら、DBの書込み処理の内容を決めるとこの処理で問題が発生しているはずだ（←予想情報）
調査が長期化したり、複数人で調査しているときにありがちなんですが、いつのまにか予想情報が事実情報に置き換わってるときがあります。
”予想情報”なのか”事実情報”なのか、区別をはっきりさせながら調査していきましょう。
解析結果を伝える役
解析結果を伝える役目の人はシステムでの発生した事象を偉い人やお客さんに分かるように翻訳して伝えることを求められます。
実はこの解析結果を伝える役目って、3つの役目の中でかなり差が出る役目なんですよね。
例えば、システム障害の内容をこんな感じで報告するエンジニアの人いませんか？
ｘｘ画面のオンライン処理でエラーが発生してます。後続シーケンスが動きません。
・・・
まあ、間違ってないんですが…
この伝え方、めちゃくちゃもったいないです！！
こんな感じで報告することもできます。
ｙｙ業務で使用しているｘｘ画面で不具合が出てそれ以降の業務がストップしてます。この業務、普段、お客さんは毎週金曜にまとめてやってるようですが、全体としてはｘｘ画面で入力したデータを1ヵ月ため込んで、月末にお客さんの取引先会社のシステムにデータを渡す機能です。
お客さんとの交渉次第になりますが、実質的なバグ改修のデッドラインは月末になると想定します。
どうでしょうか^^
↑は少し大げさにお客さん業務の視点を加えてみました。
デキるエンジニア感が結構出てると思いませんか？^^
実際のシステム障害のときは↑のセリフの最後に最短でバグ改修できる期間を報告すれば、現場から上位層への報告は完了するレベルだと思います。
このように、”解析結果を伝える役”は付加価値をつけやすい特徴があります。
今後の方針を判断する役
方針を判断する役は会社のえらい人、場合によってはお客さんの役であるがあります。
よくある判断パターンは次のような感じですね。
- 今回の障害はそれほど影響度が大きくなく発生頻度も低いので、期間を十分にとって修正する。
- いったんは一時的な手動対処で乗り切れるので運用メンバーの手間はかかるが、しばらくは一時的な対処を継続。その間に開発メンバーがバグを改修する。
- 連日徹夜してでも、是が非でも最速で修正する。
※徹夜対処は開発メンバーを酷使するので、別のバグが発生する可能性があります。信頼性が求められるシステムの場合はあえて時間をかけて改修する場合もあります。
そんな判断をします。
規模の小さいシステム障害だと、現場のリーダーが判断したりすることもありますよ。
いずれにしても、現場開発メンバー、お客さんやユーザなど全体感を見て判断する必要があるので、エンジニア的な能力というよりはビジネス的なセンスが求められます。
システム障害のとき自分がどの役回りを担当すべきか考える
ここまでで解説でトラブル対処時に必要な要素や役回りを紹介しました。
これまでの内容を踏まえた上で自分はどの”役”を行えばいいか、日頃から考えておくのをおすすめします。
組織で働いている以上、求められる役回りと自分がなりたい役回りがあると思いますが、ボクのおすすめは”解析結果を伝える役”です。
システムを解析する役はダメなの？
ダメというわけではないですが、”システムを解析する役”はレッドーシャンなんですよね^^;
システム障害は”第六感”が有効になることが結構あります。
エンジニア
なんかここ怪しい気がする…
ベテランエンジニアの↑のような”第六感”や”勘”と呼ばれるものは不思議なことに結構あたります。
ITなのに第六感ってなんだよって話ですが、結局のところ、”第六感”や”勘”と呼ばれるものはベテランエンジニアのこれまでの経験なんですよね。
- システム開発中に出てきたバグ対処の経験
- 先輩SEから口頭で受け継いできた情報
- これまでのシステム障害対応の経験
このような経験が積み重ねって”第六感”や”勘”という形で出てきます。
また”方針を判断する役”ですが、実のところ、お給料的な話をすると、このポジションが一番いいことが多いです（笑）
”方針を判断”できる立場にいるということは何らかの役職を持ってることが多いですからね^^:
やれればいいんですが、やれる立場になるのも一苦労です。
ということで、”解析結果を伝える役”はビジネススキルを磨いてお客さん業務の情報を収集しておけば、ITスキルがそこまででも、また出世してなくてもその役をできるんですよね。
さらに、解説のところでも紹介した通り、解析結果を伝えるポジションは付加価値がつけやすいのもでかいです。
正直なところ、やってることはシステム的な事象をビジネススキルを使って得たお客さん業務の知識を足し算して、解説しているだけ。
だけなんですが、残念ながらこれができてるエンジニアはとても少ないんですよね^^;
その分できるようになるとお客さん含め周りから、かなり重宝されるのでおすすめです。
まとめ：トラブルで必要な要素を知って自分の立ち位置を決めよう
この記事では次のようなことを紹介しました。
- システム障害は一次調査と二次調査に分類できる
- 一次調査は発生事象を解析し、影響内容を把握して一時的な対処を検討/実施するを素早く行う必要がある
- システム障害では3つの役”事象を解析する役””解析結果を伝える役””今後の方針を判断する役”が求められる
- ”解析結果を伝える役”は競争相手が少なく付加価値を付けやすいのでおすすめ。
いかがでしたでしょうか。
”解析結果を伝える役”の紹介のところで少しお話しましたが、ビジネススキルを持ったエンジニアはとても貴重です。
ボクが億プロジェクトのPLになれたのも100冊以上のビジネス書を読んで仮説思考、論理思考、エッセンシャル思考などのビジネススキルを習得したからなんですよね。
なので、100冊読みましょう！と言うのは簡単なんですが、めちゃ大変だと思うので言えません^^;
ですが、最近、ビジネススキルを習得するのにいい無料動画を見つけたんですよね。
ボクが実際に見てどんな内容だったか記事も書いてみたので、気になる方はこちらをクリック（タップ）いただき見てみてくださいー
それでは！！
最後に（おまけ）
ボクは新人の頃、部署内でも有名なポンコツエンジニアでした^^;
プログラミングなど、ITに関するスキルが壊滅的だったのです。
ですが、今となっては社内で最短昇格を達成し、ボーナスも6回連続最高評価を達成しました。
こう言うと、なかなかの怪しさですよね（苦笑）
ということで、やまさんのエンジニア人生をプロフィールとしてまとめてみました。
ITスキル壊滅だったボクがどうやってエンジニアとしての活路を見つけたのか、気になる人は見てみてくださいね^^
プロフィールを読んでもらえれば察してもらえると思いますが、ボクはITスキル平凡な凡人SE。
めちゃくちゃプログラミングができるなど、特別なITスキルは持っていないです。
そのためか、昔は
- エンジニアになったはいいものの、IT技術に関して興味を持てない…
- 平凡なITスキルしかもってないのにエンジニアとしてやっていけるのだろうか…
- IT技術を身につけていくだけでエンジニアとして食べていけるのかな…
- 移り変わりの早いITの世界で永遠とIT技術の勉強を続けられる自信が…
このような悩みを抱えていました。
おかげさまで、プロフィールに書いたあるきっかけから↑のような悩みは解決してます。
ですが、実はバリバリのエンジニアの方でも「ITの勉強しない→エンジニア失格」という空気感にしんどさを感じてる人は多いみたいなんですよ…
というのも、「勉強しない→エンジニア失格」の空気感について、こちらの記事でまとめてみたところ、かなり人気なんですよね。
このブログの中でも人気の記事なので、気になった方は一度見てみてください^^
最後まで読んでいただきありがとうございました！！
処理が異常終了した…