【後編：障害対応、属人化から脱却の秘訣】発生しても慌てない障害対応の勘所 / 障害対応時に持つべきメンタル / ビジネスサイドとの軋轢を生まないために / インシデントコマンダーは誰がやるべき？
ま、発生しても慌てない。 はい。 え、障害対応の感どっていったところをお伺いできればと思うんですけど、あしないのどうすればいいですか? ま、あはします。 します。あたふしちゃうもの。 うん。これはもうしょうがない。うん。 た、その中のお守りとして助けてくれる人を作っておく。 うん。じゃ、裏を返すとは やってはいけないことみたいなところで言うともうわかんないけど自分で抱え続けちゃうことが 1番多分みたい。1 番多分ですね。このみんなに 遠慮なくしちゃっていいんで。 うん。そこを抱えてしまうのが1 番アンチパターンですね。なんでこんな障害起こしたんだみたいな。 そうですね。 光り付ける文化とかがあったら障害が起きた瞬間にはい。 また怒られると思って連絡をちょっとしなくなっちゃうとか はい。ありそうだなて。 めちゃあると思います。少なくとも障害対応時はみんなちゃんと優しく受け入れてあげてほしい。前向きに障害対応を捉えようとしないとどんどんどんどん悪循環にますね。ここまで前半でもう設計は本当にコミュニケーション大事だよ。 [音楽] そうですね。 でかつ優先順位が大事だよってお話をいただきましたと。万全に準備をしていても、え、起こるものは起こります。 起こります。はい。 いうとこで後半は、ま、発生しても慌てない。 はい。 え、障害対応の感どっていったところをお伺いできればと思うんですけど。いや、慌てます。 慌てますね。そうなんですよね。 あ、ふしないのどうすればいいですか? ま、あはします。 します。 まず、えっと、赤しないためには1 番はやっぱさっきの準備をするとかとどういう基準で自分が動く、どんなアクションを持ってるかっていうのが本当はやりたいです。 うん。ただ、えっと、1 番は、あはしてしまうので、あしちゃって自分できないと思ったらベテランに連絡をできる。 うん。それがなんかお守りになるので、 まずはその助けてもらえる先がある。そこで安心してもらうのが 1番だと思います。うん。うん。うん。 で、この障害対応ってちょっと特殊な状況になってまして、一般的なこの危機対応というものは本当は専門の人がいることが多くって うん。 ただ私たちみたいなシステム障害対応してる人は普段運用とか開発とかしてて障害時だけちょっと役割が変わる。 一般的っていうのは例えば建築現場とか医療とかそういう話ですか? あ、そうですね。例えば医療だと救急外来って 緊急時北用の人が専門で当たったり 家事の時もえっと消防士が駆けつけたり ああ、そういう意味か。はい。はい。 で、普段その緊急時の対応するのに準備してる人が当たるってことが多いんですが、システム障害普段何も関係ない開発をやってる人が突然ロールが変わるんで ああ、2つのことをやってるんだ。 そうなんですよ。 自然災害も普段公務観光長で公務をやってる人が突然役割変わる。 はい。 ていくつかあるんですけど障害対応は結構難しくてふしちゃうもの。 うん。これはもうしょうがない。うん。 ただその中のお守りとして助けてくれる人を作っておく。先ほどのベテランの人にちょっと私まだ心配なんで こういう時連絡していいですかね?て言っていいよと言ってもらったりベテランの人が うん。全然連絡していいよと 言ってくれるのが1 番ふしない秘訣ですかね。 じゃあ裏を返すとはい。 やってはいけないことみたいなところで言うと もうわかんないけど自分で抱え続けちゃうことが 1番タブーみたいな。はい。1 番タブですね。 あの、こう自分で引きこもってしまってなんとかやり遂げるんだっていう風に思ってしまう人が多いですね。 責任感強い方多いっすもんね。 うん。こう私も2年目の時に こうマジでわかんないんですがなんとかしなきゃと うん。で、夜中の確か4 時だったんですけど連絡やっぱ怖くてできなくて はい。 そこでずっと引っ張ってしまって朝8 時に上司に連絡して 日がやっぱり大きくなっちゃったっていうのがあって うん。ありそう。 いや、そこを、えっと、恐れずに連絡する。騒ぐっていうのが 1 番大事。このみんなに遠慮なくしちゃっていいんで。 うん。そこを抱えてしまうのが1 番アンチパターンですね。 なんかそこって精神的な日頃のコミュニケーションもある気がしてて、 まさに前半で言っていただいたみたいにベテランの人がうん。 あの、いつでも電話していいよって言ってくれるとだいぶ軽減するし、 あとは障害が起きた後の対応 次第でもそこのハードル変わる気がしてて、例えば うん。 なんかめちゃくちゃなんでこんな障害起こしたんだみたいな。 そうですね。 文化とかがあったら障害が起きた瞬間に また怒られると思って連絡をちょっと しなくなっちゃうとかはい。 ありそうだなって。 めっちゃあると思います。 障害対応は結構私もこう明るく喋るようにしてこ悲観的になっちゃうものが多いんですがですね。 暗くしたら結構辛い悪循環に陥ってしまって うん。うん。 初外起きてその後反省とか振り返りとかもちろんするんですが、少なくとも障害対応時はみんなちゃんと優しく受け入れてあげてほしいです。 それは是非上手の方とかベテランの方はうん。 いや、ここもしイライラしてしまうんだったら頑張って優しく受け入れる。で、その振り返りとか故障訓練ってのも比較的に前向きにやっていくようにしていかないとどんどんどんどん悪化していきます。 だし、えっと、結構人がやめてってしまうようになるんで、 明る 明るく楽しくと言うとちょっと言いすぎですけど、前向きに障害対応を捉えようとしないとどんどんどんどん悪循環にきますね。 いや、分かります。なんか僕の知っているケースで言うと はい。まさ、まさにSI の友人がSIをしていましたと。はい。 で、障害が起きました。 そん時は表向き大丈夫大丈夫焦らずやってって言って終わった瞬間にああっ無償対応だみたいな この件赤字だよみたいな が聞こえちゃうしま実際多分そうじゃないですか はいはい ビジネスサイドからするとその時間が長けが長いほどああ字幅が減っていく赤字赤字赤字ああ失敗になる消しを投入しなきゃみたいに はい なっちゃってそうするとなんか頑張ってんだけど報われないというか うんそうなんですよへえ。 で、私はこういう形がやなんで、SIは やめて事業会社に行きますみたいな なりますね。山ほど聞いてきました。 いや、めちゃめちゃあります。いや、是非システム発注してる人たちにはそうは言わないとあげてほしいです。彼らも責任感を持って頑張っている ので、それを前向きにじゃ、起きてしまったことが月起きないように うん。 どうするかっていうのに目を向けていただけると事業会社のいる人もビジネスサイドとエンジニア大体分別れてるんでそこの圧歴がやっぱ出てしまうって聞いたことがあってうん。 そうならないようにしていかないといけないですよね。 うん。 で、そうすると先ほどみたく今大体の組織でビジネスサイドは障害対応に関わらないっていうスタンスになっちゃってるんですよ。 ああ、そっか。街の姿勢になっちゃうのか。 そうなんですよ。あの、結局は起こしたや が悪いっていうのはこの会社間もあります が、組織感もあってビジネスサイドは俺ら 関係なてなっちゃうんですが、実は ビジネスサイドにもできることがあるし、 実はこのビジネスサイドの方に知って ほしいのは障害対応どんな対応するかに よっていい印象、印象変わるんで、これ ビジネスチャンスなんですよ。確かに めっちゃチャンスです。 しかも他の人大体やってない。 うん。 ので起こした時にいい対応をするっていうのをビジネス側のことも一緒に考えてもらって起きちゃうのはしょうがない。一緒にどうやるかっていうのを考えるっていうのが 1歩前に進む秘訣かなと思います。うん。 確かに極端な話ごめんなさいってるだけよりも大体手段をエンジニアと話して そうす知ってれば それを提案できた方がお客さんはなんか止まってることに対してだから業務が動かないことを動かしたいだけだから そうです。そうです。そうです。そうです。 手段提案することができる営業かどうかで結構変わりますね。全然変わります。しかもあのシステム視点でエンジネやはり喋ってしまうのでサービス視点で喋ってくれるとユーザーの方は喜ぶ。 うん。うん。 で、ビジネスの人もサービス視点でどうなってて逆に言うとシステムの人が何に困ってるかを 1 度話してみてもらうといいんですよね。過去起きた大きい障害でビジネス側の人は逆に知らなすぎるシステムのこと。 障害の時にどんなミドルでどうなっていて何が起きるとやばいのか それを少し話しとくだけで結構変わってくるんで是非過去起きたものを 1 度話し合ってもらえるとどんどんどんどん良くなってくと思います。 確かになんか具体例で言うとエンジニアはついついこのデータベースが壊れてるから ここにアクセスできないからユーザーは誰も使えないんですって言っちゃうんだけどよく聞くとあ新規登録はできるのみたいな だとすると既存のユーザーさんにごめんなさい今だけ臨時のアカウント払い出したんで こっちだったらできますとか案内も そうそうそうそうそうそう できるみたいな話ですよねそれを大体マネージャーの方がこう変換を今頑張っちゃって ここがボトルネックになりがちなの で、で、エンジネの人はサービス目線なさすぎる。 逆に言うとサービスの人はサービス目線持ってる素晴らしいんで、エンジニアことを少し分かってあげるっていうのとても大事だと思います。 うん。うん。なるほど。そんな形で起きてしまったらあたふするんだけど はい。 え、まずは先輩に連絡したりとかしながらみんなで対応しでその中にもま、その第 1 歩の次かもしれないですけどビジネス側の人も巻き込んでいくっていうのが 結構重要ってことですね。なるほど。なるほど。 連絡しました。みんなで当たってます。そん中でも僕はよく思うのがまずは復旧させてほしい。 はい。 さっきの前半であった再起動の方するとか、ま、応急処置ですよね。 応急処置の対応して欲しいんだけど調べていったらここっぽい、ここっぽい、ここっぽい、ここっぽいって入ってくと復旧させるよりも先に調査を走っちゃうっていうケースが結構あると思 い。ありますね。はい。 なんかここのわゆる順番 はい。大事だなと思うんですけど。 めちゃ大事ですね。 ここら辺もありますよね。 ありますね。あの、先ほどの籍の中で言うとシステム目線じゃない、視点じゃなくてサービス視点でっていう話を書いてあるんですが、これエンジニアやはり原因を調べたくなっちゃう 生き物でこの目的はユーザーのサービスが暫定的に復旧することだ。これ結構しっかりお伝えしないといけなくて、 これがマネージャーもしくは世の中でいうインシデントコマンダーの人がコントロールする 1番大事なところですね。 うん。うん。うん。そうですよね。 じゃないとついついあの100% に戻すことを優先したんだけど いや今はそれより先に30% でいいから動くようにしてくれっていう状態の はい。 なんかボタンのかけ違いが起きちゃいそうですよね。 起きちゃいますね。 かつあの集中し始めるとこう集中しがちでなかなか戻ってこないんで、こちらからマネージャーもしくはエンジレントコバンダーからしっかり連絡を定期的にしてあげないと こう永遠に原因を掘り続けちゃう んうん。 本格対処考えちゃうじゃなくって暫定的にこのサービスが止まってるのはクリティカルなんでていうのをしっかり伝えるのは大事です。 うん。 [音楽] なんかそういう意味では今いいキーワードが出てきたんで、インシュデントコマンダーっていわゆるその何か起きた時にそこの指示命令系統を司かさとる人だと思うんですけどインシデントコマンダーは一般的にどういう役割の人がやってくのが 1番いいんですか? インシデントコマンダーは一般的には、え、そのエンジニアリングマネージャーとかプロダクトマネージャーやることが多いと思うんですが、私が思うにはもっとビジネスサイドの人ができるようになるべきだなとは思います。 お、いいですね。 これ私がエンジアりなんで言うたなんですが、やはりちょっと気が引けて一歩下がってしまう。 うん。 で、今サービスをどの状態に戻すと復旧するかっていうのを分かってるのはビジネスサイドの人のはず なのでビジネスサイドの人が優先順位をつきながらでエンジニアの人はどうせ巻き込まれてる状況なんでうん。うん。 ビジネスサイドの人で役割が持ってると1 枚いい。うん。 うん。ただ全く理解できないと苦しんじゃうんで、是非のインジレンドコマンダーの役割を通してシステムのことを分かってもらう。 あともう1つは心が強い人ですね。 うん。このシステム障害心辛いので こうちょっと心弱めの方はまた次回にしといて。 心強めで、あの、インシントコマンダーはこの経営からの依頼も全部断るべきみたいな 暫定復旧最優先でみたいな結構強い 確かに 意思を持たさるを得ないのでちょっとビジネスサイドかつちょっと心が強くて上にもちゃんと対抗できるような人がなると一のコマンダーいい役割になるかなと思います。 確かにカジ場のリーダーシップですもんね。 そうですね。 兵事じゃないからまた向いてる人変わりそうですよね。 変わりそうですね。 ただですね、このエンジニアで好きな人いっぱいいるんですよね。 やりたくなっちゃう。 やりたくなっちゃう人いるんで。 よしっつってカジ場になったら俺の出番だっていう人結構います。 います。います、います。うちもやっぱ好きな人いるんで。 そういう人に任せちゃうとまたまた独人化しちゃうんで、ちょっとこうだんだん分散させるのは考えつ、どっちかとビジネスよりの人でそれが成り立つと組織としての続人化が減っていくっていうことには至るかなと思いますね。 そんな形で、え、一方から、え、復旧のところのインシデントコマンダーまで行きました。で、復旧しましたってなったら はい。 人段落で、ま、発表終えて化したとしますと、多分次にやってくんのが、ま、振り返りであったりだとか、ま、ポストモーテムっていうやり方を取ってる方もいらっしゃると思うんですけど、ここはなんかどういうポイントを大事にすればいいと思いますか? 振り返りはですね、是非前向きな感じで明るく楽しくやっていただけると、ちょっと明るく楽しくは言いすぎかもしれないんですけど、やはりこう振り返りをつみたくなることが多くて [音楽] はい。反省会にしないみたいな。 そうなんですよ。おっしゃれとおっしゃったです。 あの、こう反省じゃなくて起きちゃったものを次どうするかがメインの議題であって、こう怒られることがメインじゃないよね。 こう大体こう10 数集まって振り返りやるぞってなるんですが、ちょっと発言しづらい絶対怒られるんで。 はい。 先犯を探すみたいなそうなっちゃうんですよね。ま、それは、ま、やっぱり原因となったものは分かりたいんですが、これが、ま、起きちゃったのはしょうがないと うん。 次、起きないようにどう前向きにするかっていう是非この振り返りを仕きる人には前向きに明るくり返りを進めるっていうのをやっていただきたいですね。 うん。 だ、ま、明るくっていうのはなんか楽しくわちゃわちゃやるというよりもちゃんと前向きにこれが見つかったのが学びだねとか。 そうです。そうです。そうです。そうです。 これは高級対策を取った方がいいねとか。 これは今回、え、緊急対応でやったから、 え、この先も、え、やんなくても大丈夫そうだねとか色々そういう意味での前向きってことですよ。 おおしゃれ通りです。 次、今回起きてくれたからこそみんなで意識が上がって、もしかしたら大規模な障害起きたのが防げたかもしれないと。今気づいてよかったねっていうのをみんなで是非見つけていただきたいですね。 確かに。なんかこの余心があったからそれで対応すれば 本、本揺れを防げたみたいなのもありそうですね。 ありそうです。 されそうです。是非そこでえっとしかもですね、障害対応振り返りの時っていうのはすごいチャンスでして うん。 なかなか障害対応の改善って普段できなくて はい。 なかなかこう忙しい中でつ起きるかわかんないやつなぜやるんだとテンションもみんな上がってこないんで発生した直後がチャンスです。改善できる。 はい。 よくできるチャンスなんで、現場の人もちょっとここまでやっておいた方がいいんじゃないですかねって言ってうまく取り込んだりとか、前向きに次の改善、もしこうなってたらもっとやばかったですね。じゃあここまでやっときましょうよっていうのをみんなの安心のためにも前向きに取り組みたいですね。 確かになんかプラスに考えるとそこで起きてしまった頃そからこそ前々から持ってたこの優先順位上げようとかそう 日常の開発の中でここをちょっと上げようとかまさに設計の見直しをもう 1時間この後やってみようとかはい。 そういう話に繋がるっていう意味ではポジティブな捉え方もできません。 ぜ非と、あの、ポジティブに捉えてください。 で、多分それで一通りのわゆる障害対応は終わるんですけど、あの、本当に理想だけど本当にできてないのが障害対応の訓練。 ああ、難しいですね。 例えば有名なところだとNetflix とかがもう自分たちで壊すシステムで すに壊させてるみたいな KOモンキーってやつとかやってたりすると思うんですけど。 はい。 そんなの余裕がある会社の話でしょってなりがちだと思うんですが、 まずそういう訓練をやろうっていうモチベーションってどうやって同期づけすればいいですか? 1 番私が知ってる中であるのはあるルールに乗っって 1年に1 回どうせやんなきゃいけないからそれに乗ってやるっていうのが多いんですがどちらかと先ほどの障害の振り返りとしてこれ 1 回訓練やった方がいいよねっていうのを提案するのが一番きっかけは作 やすいですかね。ああ、確かに。 はい。訓練やりましょうって言って賛成してくれる人いないんでだって極端なんし会社の避難訓練とかみんないやいやでやってますもんね。 あ、そうです。そうです。あれを意味あるものにするってのは個人的におすすめですね。 うん。例えばルール上1年に1 回何らかの訓練やんなきゃいけないんですが、おそらく避難訓練的なものをやってると思ってて、うん。 そのドキュメントを開いて、 絶対障害時開かないドキュメントを開いて、こう指でぞって事前にこの明日訓練なんで、何時何にこうやってくださいね。いや、意味ないと私は思ってて。 うん。確かに。 それであればもうちょっとスパーリング的な はい。はい。 こんなことが起きたというシチュエーションでみんなでわちゃわちゃやってみよう。 はい。 っていうものをやってみたり、それもシステムの、え、わざわざ障害を起こすとかって準備が大変なんで、気でも十分うん。 えっと、何月何日に起きた障害のログとか状況をこう持ってきて、それを後頭で気上訓練っていう机の上の訓練んですが、それで本番さがのテンションでみんなで 30分1かギュってやる方がああ、 学びが多いです。 シミュレーションしてみるってことですね。 そうです。そうです。 あの、ベテランの人がいないという状況で若い人がこれから今サービスが全部止まってるから再起動してとで、その手順分かるって言われたら、いや、ちょっとわかんないですって絶対になりますし、このログ調べてって言っても取り方がわかんないですとかってやっぱりなりがちなので、 そこの 実践的な訓練を普段のこの避難訓練的なものは置き換えてやってくってのが 1番効果がありますね。そう考えると こう日常の中でそれこそさっきのポストモーテムが起きたタイミングとかって 1番みんなの熱曜上がってるから そうそうそうそう 提案しやすいし通りやすいっていうのもあるかもしんないですね。 はい。逆にそこでしか通らないのが今のこの紹介の難しいところですね。 うん。なんかどうしてもこう保険みたいな見られ方をしちゃうというか。そうですね。はい。 あのここで一戦も生産まないじゃんって言われたら 確かにそうなんだがただ未来の損失を減らしてるという可能性もある。 はい。めちゃめちゃあります。はい。 ただその可能性何パーセンですかみたいな議論になっちゃいがちですよね。 なっちゃいますね。はい。 なんで行って起きたのに合わせて徐々に対応してくってのが 1番すですかね。 うん。そんな感じで避難訓練まで行きました。 ここまで行けばアタフターするんだけど、ちゃんとしっかりできて 1回の、え、ひ消しも終わって それを再現してもう1 回できるようになって、ここまでできるとだいぶ心が休まるというか、 日道の開発に集中できる状態になってきますかね。 そうですね。はい。 あの、続人化もこう排除できて誰でもちょっとは少なくとも前に行って徐々に良くなるっていうところに行けるかなと思います。 うん。 なんかそういう意味ではここまで行けるだけでだいぶすごいと思います。 はい。 ただあの愚直にいや、野村さんの教えを受けてやりました。次くださいって あ 言われたら次もう1 ランク上のことをやるんだったらどういう提案をしますか? ああ、もう1 ランクやるんだったら是非この本を買っていただいて 確かにこん中にいっぱい書いてある。 はい。 あの、多分今日皆さんにお伝えしたのはどちらかというとあんまりうまくできてなくて 1 個目を踏み出すみたいなもの中心にお話ししたので、ちょっとこの形に沿って綺麗にやるっていうものまでちょっとやりきれないかなと思ってて、で、この書籍の中だと 3ヶ月で順番にこう処理してく、 あ、そうですね。 ていうのを書籍に書いているんで。じゃ、野村さん、この本のポイントをお伺いしていいですか? あ、はい。ポイント3つありまして、1 つ目がシステム視点じゃなくてサービス視点 うん。うん。で、2 つ目がえっと自称ではなくてアクション うん。で、3 つ目が情報の量ではなくて質というものになってます。 キャッチーですね。 キャッチーなの作ってきました。分かりやすく作ってきました。 詳しく聞いてもいいですか? 分かりました。1 点目の、え、システム視点じゃなくてサービ視点っていうものなんですが、結構こう障害対応をしてるとエンジニアはこう無邪にデータベースが壊れましたとか 言っちゃいがちなんですが、ビジネス側からすると でどの機能が使えないの毎回毎回なってそうそうそうま分かったわかった。 で、何なのってよくなりがちなんで、障害の時の、ま、エンジニアがそう言っちゃうのはしょうがないんですが、サービスの視点としてユーザーにどう見えてるか、どうなっちゃうか。 うん。うん。 こちらのサービス視点を重視するっていうのが障害対応時の 1番のポイントになってきます。うん。1 つ目がそれ。はい。じゃあ2つ目は2 つ目実証ではなくてアクションていうものなんですが、結構障害対応未知のものどうしたらいいですかっていうものを聞かれるんですが、未知のはやっぱりわかんないです。 ふんふん。 ま、しょうがないで、こう、私も10 数年この障害対応どうしたらいいのかなって思ってたんですが、そこで分かったのが自称っていうのは技術の進歩と変わってっちゃうんですが、とりアクション、アクションってのは暫定対応とか どんな連絡をするか、 これはあんまり変わらなくて収束していくなってのが分かってきまして はい。なのでどんな事象かってよりもこと が起きた時にどんな復旧をするのか、 どんな連絡をするのか、例えば再起動、ま 、再起動のやり方はシステムによって 変わっちゃうんですが、再起動します。 もしくは偏せします。もしくは生します。 連絡であれば個別で電話をします。一斉に 連絡します。 レブを計算しますという事象ではなくてアクションに注目して障害対応の整理をするとだんだん収束してきて 永遠に使えるものになるというのが2 つ目のポイントですね。 確かに実はもうパターン無限にあるけどアクションは有限ってことですよね。 あ、そうです。そうです。そうです。そうです。意外にこう収束してきて一定の量で音るのでそちらを磨いてく方が初対応としては良いものになってきます。 じゃあ最後3つ目。3つ目。 えっと、情報の量ではなくて質っていうものなんですがうん。 この障害対応を参加する人の悩みで1 つ色々なことを言われた中で特徴的だったのは情報量が多すぎて分からないっていうもの。 ああ、ありそう。 スラックだとかチームとかで皆さんこう情報がバーっと流れててで俺は何すればいいのって思ってる方が意外に多くって この量を こう積み込むことにみんな集中しすぎちゃうんですね。 はい。 なのでもしかしたら八塚さんもこう障害起きてる時に何でもいいから情報ちょうだいって言ったことあるんじゃないかなと思って エンジニアがこう調査に集中しちゃうんですが何でもいいからちょうだいって言われると 結構このエンジニアが固まっちゃって 本当に何でもいいから渡しちゃう でたくさんの情報を得るとそれはそれでよくわからない でビジネス側の人はもっとよくわからない うん で質というもので言うと先ほどのアクションの再起動するのか連絡するのかこれを判断するため の情報とその基準っていうものだけを集めるっていう風に質を高めていくとみんなが混乱しないでくと [音楽] うん。 なので量を集めるよりもいい質の情報集めるっていうのが重要になってきます。 うん。なるほどな。確かになんかよくやるのがもうことでいろんなやり取りしちゃうとあれだから情報の場所も集中させましょう。 そうです。はい。 で、その中でちゃんと意思決定に必要な情報だけを、ま、ある意味絞るみたいなところが大事ってことですね。 はい。大事ですね。はい。 いや、なるほど。 なるほど。それを起点に3 ヶ月でどうやっていくかがこの本に書かれているっていう。書 かれてます。この本読んでいただければ障害対応 3 ヶ月で必ず良くなるんで是非ここにやっていただくかもしくは私に相談いただいて個別に相談いただければいくらでも相談乗りますので うん。今そうですもんね。だからそのインシデントに対応する会社もえ一緒にやられてるって感じですもんね。 あ、そうなんです。 あの、インシレンドテックという会社をやりまして、そこはシステム障害対応をどう改善するかというもので、今は皆さんの意見を是非聞きたい時なので、困ってる方是非相談いただいて うん。 この書籍もしよければプレゼントできますし、 お是非読んでこの この動画も共感してさらにもう1 歩踏み出したいんだって肩に5 冊プレゼントいたしますので 概要欄にあのGoogle フォムを置いていこうと思うのでそこから申し込んだ方抽選で 5名様はい にプレゼントできたらと思っております。ありがとうございます。 是非っぱらありがとうございます。 ありがとうございます。 それちょいや、ありがとうございます。いや、前半後半と全体的にやっぱり前半でちゃんとしっかりコミュニケーション取りながら設計していこうね。そこでまず万全の準備をする で、万全の準備しても、ま、タフタはする。 はい。 あはするからその中でもちゃんと連絡を取りながら、そして連絡を取る中にはビジネスの人も入れながら、そして振り返りはあの反省会にせずに、そして避難訓練みたいにならない。 ちゃんとシミュレーションの訓練をやっていくと、え、まず 1歩目踏み出せるかなってはい。 感じですかね。 すごい初塚さんばっちりまし。 いや、いや、ありがとうございます。なんか最後にもう一言伝えたいこととかありますか? ちょ、さっきと話してたこと結構近いんですけども、障害でエンジの人は結構こう孤立してる人が多くって うん。うん。それはベテランの人が障害 対応を頑張ってるとてもいいエンジニアが 孤立してるはずなので是非若手の方はその ベテランが孤立しないようになんかできる ことあったらやりますよってのを先ほどの 30分に1回の中で受けてもらったりで ビジネス側の方も実はこう声かけてくれれ ばいいのにと思いつつエンジニアなかなか 声かけづらい人もいると思うんで是非1回 なんか困ってることないと前 回こういう時にもし自分たちができることがあったらやるよっていうのは是非一声かけていただいて 1 回コミュニケーション取る。この動画見終わったら 明日ですね、とりあえず 連絡してみましょう。是非1 回チャットでなんかあるってところだけ是非いただけるとありがたいです。 ありがとうございます。というわけで今日は障害対応続人家からの脱却の秘訣を、え、野村さんにお伺いしました。ありがとうございました。 はい。ありがとうございました。 [音楽]
チャンネル登録、高評価よろしくお願いします🙇
▼書籍プレゼント応募フォーム
https://forms.gle/MFKxRuX7EQtwm91HA
※ 抽選で5名様にプレゼント
※ 当選の発表は商品の発送をもって返させていただきます。
▼ 前編はこちら
https://youtu.be/jjzFOknk4Ro
▼ゲスト
野村 浩司 | 株式会社インシデントテック 代表取締役社長
株式会社NTTデータで、金融システムの開発保守運用と改善を12年担当。7年にわたり合計約1000件の障害事例を分析し、エンドユーザーの影響極小化を目指したインシデントレスポンスサービスの企画運営を担う。社内外100チーム以上のシステム障害対応の改善に取り組んでいる。システム障害対応の改善と、人々が助け合える世界の実現のため、2024年4月に株式会社インシデントテックを創業。
著書『3カ月で改善!システム障害対応 実践ガイド （共著）』（翔泳社、2023年）
X：@nomurakuj
▼MC
蜂須賀 大貴 | テクノロジーメディア「Newbee」代表
メディア・エンタメにずっといて、テレビ、映画、CM、広告、配信、YouTubeの現場でプロダクトを作ってきました。PodcastやDevSumiコンテンツ委員などもやってます。
ex-PIVOT,サイカ,IMAGICA etc.
X：https://x.com/PassionateHachi
▼目次
00:00 ダイジェスト
01:04 障害が発生しても慌てないために
04:56 障害対応時に持つべきメンタル
06:50 ビジネスサイドとの軋轢を生まないために
11:24 インシデントコマンダーは誰がやるべき？
13:38 振り返り設計のポイント
16:20 障害対応訓練の動機づけ
20:20 障害対応のネクストステップ
#障害対応 インシデント対応設計