【前編：障害対応、属人化から脱却の秘訣】設計の優先順位の付け方 / ビジネスサイド/エンジニアの共闘方法 / 世間の「当たり前」をしっかりやるために / ベテランの振る舞いが鍵 / 遠慮を外す方法
独人化を解く鍵みたいなところは極力いろんな役割で話すみたいなところが大きいんです。はい。 1 本目としてはそれだと認識します。あのお勧めしてるのはエンジニアチームでエテランの方に毎週 30 分先週来た障害を喋ってもらうっていうのはすごいおすすめです。ベテランの人がいや俺に集中してるなって思ってる一方で若手はあ、あのあの人にお願いいしちゃって申し訳ないなって思ってる嫌いが大体のチームであります。 はい。はい。 自分が若手エンジニアだった時も はい。なんか2 つのことが攻めぎ合ってるんですよね。1 つは 任せてもらったから自分がな何とかしなきゃっていう。 2つ目はそう遠慮はい。 重厚調大のドキュメントを作るのがなかなか難しいんだったらまずは 1週間に1 回その遠慮をどう外すかっていうのがあれめちゃ大事。 来週の定例ミーティングで、え、ベテランの方にいや、俺 24 時間つでも電話していいから言ってもらえる時すぐ始められました。 あ、めちゃくちゃいい。 それだけで若手がどれだけ救われるか。 確かに。 皆さんこんにちは。ニュビの塚です。え、今回のテーマは障害対応についてです。 え、特にミッションクリティカルな、え、 大規模における、ま、大企業さんSIさん 、そしてサービスを提供する方とかですね 、え、色々な方が関わっているのが障害 対応だと思います。そしてですね、今日は そんな障害対応にフォーカスしてその道の プロフェッショナルにお話を伺うと思い ます。え、ゲストは、え、こちらの本です ね。え、3ヶ月で改善システム障害対応の 著著でシステム障害対応の専門家野村浩司 さんです。よろしくお願いします。 よろしくお願いします。縦野村さんは この本出て大体1年ぐらいですか? そうですね。1 年半ぐらい経ちましたかね。 売れてますか? まあまあ まあまああの編集者の方に 専門書にしてはまあまあ売れたと ああ、いいですね。いいですね。 はい。ただその売れゆきよりも これ読んだよって言われること結構あって 実これをきっかけに出会った方もいらっしゃればこれをきっかけに講演してくださいもあって結構そのきっかけ作りっていう意味ではとてもいい本でした。 なんか僕との浦さんも面白い出会いで、 そうですよね。 僕の全職の時にユーザーさんでユーザーインタビューさせていただいて [音楽] はい。 で、本出すんですよってイベント会場で教えていただいてみたいな感じでしたね。だ、ある意味僕も改めてユーザーさんとして出会ったんですけど、この本でさらに野村さんのことを深く知れたっていう ありがとうございます。 感覚がとてもあるので、今日はこの本まだ取って手に取ってない方もですね、手に取った方もさらに 1 年半経ってさらに野村さんの中で新しいもあると思う。 めちゃめちゃあります。やっぱり出してみてユーザーとこう話をするとこう違うんじゃないとか実だよってこと言われることはあって若干本から進化してるんで是非とも 聞いていただけるとありがたいです。 い、ありがとうございます。 というわけで今回は前行編に分けてお話を伺うんですが、え、前半は、え、続人化から脱却できる障害対応設計 設計。はい。設計の方に行きます。 で、後半は発生しても慌てない障害対応の間ど所ということで 発生してからの方 という形で、え、前行編を分けてお話を聞こうと思うんですが、早速前半からお話伺っていこうと思うんですけど、ま、障害対応正直そのワードだけで目を背けたい ますね。はい。 はい。気持ち。僕も当然ながらエンジニアとかプロダクトマネージャーやってくるともう何度も涙を流しながら深夜に対応するとか はい。 なくなく切り戻すみたいなとかもめちゃくちゃあったんですけど、ここに注目されてる方って結構珍しいなと思うんですけど、その背景ってどんな感じなんですか? 元々大学時代に自信の研究をしたっていうのが本当のきっかけでありまして うん。うん。 私の卒業直前に東日本大震災が起きたんですよね。 ああ。 で、本当にこう何もないところでボランティアが集まるっていうのにすごい感動したんですよ。 日本全国から資材を投げって人が集まるっていうのはすごい素敵なことで、 それが1番の感動だったんですね。 うん。NTTデータに入社してうん。 システム障害かなり大きいものが起きまして うん。全国でクレジットカードが1 時間使えなくなるみたいな障害が起きたんです。 おお、クリティカルですね。 いや、クリティカルNHK のニュースバーンって出てはい。 当時の偉い方々も集まってきて、土曜日の夕方のお買い物時 全国使えなくなるでもう大盛り上がりで Twitter でも使えないたくさん書いててでその時に皆さんかなり協力はしてくれてるんですけどやっぱりこうお客様から厳しい言葉を頂いたり 中でもこう役割どうなんだって結構揉め事があって うんうん この自然災害だと色々助け合いたのになんで障害こんな助け合 ないんだろうてのが本当のきっかけ でしたね。で、その後やはり私自身もあの八さんと同じように 1日6回エスカレーションの電話が来て 週2 回データセンターにかけつく実は2 年目にデータセンターのハ迎えぐらいに引っ越してきたんで よく行くから よいつでも行くそこからこの苦しみをなんとか解決したいっていうのでこの障害対応を集中してやってこうって思いましたね。 へえ。 で、確かになんか人の命が関わっているとか、それこそ災害になると力一緒にできるのに同じ障害の対応って言っても急に IT の世界になるとなんか動いて当たり前でしょとか 止まらないものでしょっていう感覚がついちゃってるのか。 そうですね。はい。起こしたやつが悪いみたいな文化があって、 この文化なんとか変えたいなって思ってますね。 はい。へえ。なるほどなるほど。 地震のところからスタートしてそこに紐付けて最終的にここまで来るってなかなか聞かない経験です。 [笑い] いや、ありがとうございます。じゃあ早速そんな野村さんの、ま、ご経験から設計っていうところが今回前半でお伺いできればと思うんですけど、まず、ま、みんな重要だとは思ってるんだけど、改めて、え、復習って意味でなぜ設計が重要なのかみたいなところお伺いしていいですか? はい、分かりました。 障害対応というものがちょっと特殊な業務ですと。 うん。 普段開発をしてる時は要件定義設計して一定の時間を経ってやるものなんですが、初対応起きました。すぐやりなさい うん。 て言われるものなので準備をすればうまくできるんですが準備しないとなかなかできない。 うん。 一方であんまりないから設計しなくていい。頭回しになりがちだと。 うん。 もしかしたら八塚さんもプロダクトマネージャーやってる時に昨日優先で後にしろみたいになりませんでした。 [音楽] そういうシーンもありますよね。 ですよね。はい。 会社のフェーズとかまだ授業立ち上がってすぐとかの時はそうなりがちだったりしますよね。はい。で、これがあの同様に私が、え、所属してる大手の SIR でも同じようにやっぱり発生する時があって、その時にこう万が一が起きてしまうと指数関数的にこう被害がドーンと大きくなっちまう。 うん。 なのでどこまで深くやるかっていうのはもちろんサービスによるんですが、最低限ここだけ抑えればっていうのを今日皆さんにお伝えして うん。 最低限うまく被害が大規模になるのを抑えられと そんなことを今日お話しできればなと思います。 うん。結構これ見てくださってる方、サービス作ってる方が多いと思うんですけどうん。 例えばサービスを作ります。プロダクトを作ります。 で、ファーストリースします。うん。 多分このタイミングで本当は障害設計ができているとベストなんだけど大抵できてない気がしてて できてないですね。はい。1 番このくらいがベストだよってタイミングってどこにあるんですか? サービスのリリースに合わせてちょっとずつ成長させるのがベストだと思ってます。 うん。最初に100点を作んなくても はい。それは1番起こりそうとか1 番怒ったら怖いみたいなところから手をつけてく お仕事です。お仕事です。 と対策をする時のどの範囲守らなければいけないサービスが何か うん。 うん。例えば動画を配信してるメディアであれば動画が配信できない ていうのはクリティカルなんで。 ただユーザー登録は、ま、後でいいだろうとか はいはいはい。 あとはそのサービスが復旧する速度が最初の頃は 1 時間ぐらいま、止まってもしゃあなかなと。ただ途中になってきてユーザーが増えてきたら何分以内 うん。 ていう風にだんだんだんだんレベル上げる。それをどんな業務かあとどれぐらいのスピードかのバランスを作っていくのが 1番いいかなと思って。 ああ、じゃあ割とその障害設計の最初のタイミングで頭の中もしくは書き出したりとかしてリスト化してんだけどそこに優先順位をつけてるって状態。 そうです。そうです。そうです。そうです。 ただ一般的にはやはり事前に全部の設計をやりなさい てなるんですが、 ま、できたところを見たことは私はないですね。 ま、そうですよね。いや、でもちょっと安心しました。 いや、できないです。あの、ちょっとこれを言うとあれなんですが、やはり昨日最優先で うん。 こう大体選票上は私が知ってる限りそのいろんな会社さんと話をすると 運用設計はこう稲妻が後ろになっててもオッケーみたいなやいやいやいやみたいになるんですが 気持ちは分かる。 ただしょうがない。ただそれを許容して長らく放置してるのが 1番やばいと思いますね。 うん。うん。これを放置したまま1 年後サービスが巨大になってて大規模な障害が起きて一気に信頼を失ってしまう。 確かに これを何かどうにか抑えていくっていうのが重要かなと思います。 その障害の設計をする人は うん。うん。 どういう人なん、どういう役割の人がやればいいのかなって思ってて僕とかは経験上 エンジニア出身のプロダクトマネージャーなので こういう障害きそうだねとかなんかパフォーマンスここ気にした方がいいねって分かるんですけどそうじゃない場合とかってもうエンジニアしか分からない障害とか ああそうですね。 はたまたエンジニアはパフォーマンスは分かってる。 パフォーマンスの限界分かってるんだけど、ビジネス側の人しかこれは実は 100 万人にもうすぐ行くキャンペーンを打つんだとか知らないとか情報の格差とかで結局蓋開けてみたら障害になっちゃいましたって結構多い気がしててそういうのを考えると障害設計って どんな人がやってくのがいいんですか? ちょっと曖昧な答えになっちゃうんですがビジネスの人がやるべきことと エンジニアの人がやるべきことが違うかな両方ともやんなきゃいけないかなと思っ はい。はい。 えっと、まず先ほ坂さんがおっしゃったようにエンジニアがやること結構たくさんあって、 ただま、後回し ギリギリそのパフォーマンスはちゃんと見ましょう。 は、それはそれで重要なんですが 逆に言うとビジネス側の人がやらなすぎる傾向にはあるかもしれないですね。 ああ、なるほど。 で、具体的に言うとビジネス側の人はこのサービスだけは止めないでくれの主張が弱すぎるかもしれないですね。 優先順位のヒントがあんまりないってことですか? そうです。そうです。そうです。で、それは多分八塚さんみたいなこうマネージャーの方が言葉の変換をしてくれてると思っててビジネスサイドは実はこれ大事だって言ってなんだ。 あ、そうそうそうそう。で、そこを聞き取ってあ、じゃあこの機能だけは強めようみたいになるんですが、多分ビジネスの人はそんなのシランプリで うん。 新機能を作らせるは作らせるんですが、その価値を提供してる運用っていうものに興味なさすぎる感じはありますかね。あ あ、確かに。なんか分かんなくもない気持ちもちょっとあって、 あの、例えばB2Bだとうん。 今ここでいい提案をすれば来月には1 万人のユーザーを抱えてる企業さんと契約できるとか、 あとB2Cの場合でもうん。 来月のタイアップのマーケティングでぶわっといくんだ。それを取ることに必死で取れましたって言うんだけど エンジニアとか開発サイトからするといやそれパフォーマンスめっちゃ気になるから先に行ってよみたいなの。 いや、めっちゃあります。めちゃある の連携ミスみたいなのめちゃくちゃあります。 めちゃめちゃあります。で、あともう1 つちょっと私がエンジニアサイドにいるんでビジネス側にこんなことやるとてもいいよっていうのは うん。起きた時の大体手段とか なんて伝えるかっていうのはしっかり準備できてるとそのユーザー側の印象はすごい変わると思います。 ああ、 あの障害の時ってえっとNPS の研究をしてるような本の中でも うん。 システム障害の時の対応ですごい印象が良くなる、すごい悪くなるっていうのが変わるんですね。 いや、めっちゃ分かります。 で、ただエンジニアはま、まあまあやっていることが多い。 ただビジネス側の人が例えばその伝え方を工夫してるとかその時に必死にフォローするかもしくはじゃちょっと実はアプリ版は見えないんですが Web版だったら見えますよ。 例えば動画メディアである というのがうまく案内できるかその一歩があるかだけでユーザーの印象は違ってきてエンジニアの人とまもちろん売上を上げるのが うん 最大ミッションなんでちょっとビジネス側の方難しいかもしれないんですが 1 回エンジニアと話してみればおそんな興味持ってくれたんだってエンジニア喜んで話すと思うんで是非 1 回話してもらえるととてもいい障害対応できるかなと思っ 確かに確かにあと は、例えばそれがビジネス側が忙しかったらエンジニアサイドからビジネスを把握する動きをしにってもいいかもしれない。 それは1 番できるといいすね。なかなかそこが難しいかなと思いますが、そこを是非把握していって、ま、これ守るのは難しいんだけど、これだったらできそうです。意味ありますか?いや、全然意味ないよ、あるようなのか だけでもかなり違うと思いますね。 なるほど。 じゃ、ある意味そういった形で、ま、エンジニアと、ま、プロダクトマネージャーだったりだとか設計設計をやってる人たちとか、あとはビジネスの人たちとかがある意味チームで 話し合いながらそこの優先順位を決められるのが 1番理想だしうん。うん。 一緒に決める場にいなくてもそういう情報交換ができてると はい。 設計の上では優先順に付けしやすいって感じなんですか? おっしゃるです。 私がこういろんな講演をしていたり障害対応で第 1 歩目何したらいいですかって言われて絶対に言うのは定例会議の最後 15 分とかでもいいんで障害あったらどうしますを話し合ってほしいっていうのを言っているんですね。 あ、もしもでいいから。 はい。もしもでいいか。先ほど見たくビジネスの人を巻き込みながら、ま、本当で言うとそのセキュリティ担当とか後報担当を巻き込みながらいっぱいいるんですよね。 ただそれを全員巻き込んでやるのはあまり現実的じゃないと思ってください。 ただ例えば 本当にニュースになっちゃうぐらいやばい情報出した時って 1 歩目動きで合ってますかを1 回話してるだけで結構違ってきて よく言うエスカレーションフローってやつですね。 そうです。そうです。そうです。で、これが私も最初そうだったんですけど、やっぱ怖いんですよね。これ言っていいのかなみたいな。 そんななんかあってもいけない悲観的なこと言うのよ。 で起きちゃうだろうみたいな感じ ですし、あと夜間休日とかマネージャーに連絡すのやっぱ怖くて はいはいはい。こう1 人で抱えちゃう。これが被害を大きくしてしまう 1 番最初の一歩としてよくあるものですね。 自分で引しちゃおうとそうなんですよ。 ただわかんないんで結局被害がどんどんどんどん大きくなってすぐ言ってくれたら良かったのに。 これを若い人たちはやはり怖がっているし、この一般に補をしなきゃいけないやっぱ怖いので候補の人にもしこういうことがあったらどうですかって聞いてくれると候補の人は是非してくださいって絶対言うと思います。 はい。 これをどうにかみんなで守ろうと思っているんで、いい候補したいですし、セキュリティチームをビジネスチームも言ってくれるはずなので、これを人 1 回喋ってみて、こういうこと言っていいんだっていうのが 1歩目のもうちょっと言うとこうい い体制を作れるかどうかっていうのがあまりコストかからずにクイックに障害対応の大きい被害を抑えられる いい秘訣だと思うので是非それはやっていただけると うん。 ま、今すぐできる、来週明日にもできるいい対策だと思います。 確かに。まず話してみる。まずはうん。 ま、ちょっとでいいんで。 確かにそれが先ほど触れていただいた信頼みたいなところを いや、違いますね。 獲得できるか失うかみたいなところに直結しそうですね。 はい。そうですね。 なんかサービスが使えない時に一方来てるかどうかでユーザー側の印象すごい強く変わるので。 あ、ちゃんと丁寧に扱ってくれてるのか、雑に扱われてるのか。 うん。 そこだけで変わってくるのぜ非やっていただきたいですね。 うん。 なんかそういう意味ではなんかよくも悪くもそれこそみんなクラウドを使ったりとか色々してる中で あのサーバーは止まるものだから止まった上でどう高速に復旧していくかだったりだとか止まった時に自動で切り替えられるかとかを気にするようになってきたから うんうんうん なんか分かってくれてる人増えてきた感じは若干しますけどね。 あ、すごいしますね。私も10 年前ぐらいにやった時にあまり理解をいただけないことが多かった感触はあって、今は結構理解してくれます。どちらかというと、それはできたでしょうっていうものに対して当たりが強い。それは あ、そっか。一方言えたでしょうとか、 エースカレーできたでしょうとか。 で、あの、オペミスはやはりちょっと風当たり強いんですが、それもオペミスした後の確認で気づけたんだったらオッケーとか、 その後リカバリーしたんだったらしゃあなねと、 そのやできたっしょっていうのに対して対応できてるかどうかで信頼の獲得できる、 [音楽] 失ってしまうが大きく変わってくるかなと。うん。ああ、なるほどな。世の中がみんなある程度そういうもんだって分かってきたからこそ そうです。 当たり前にできることやってない方が怒られる。 そうです。そうです。そうです。そうです。そうです。そうです。 なんかそういう意味では今日俗人家っていうテーマが 1 つあると思うんですけど、内容によってはこの人が分かるからこの人に任せれば一旦大丈夫だつって言って 置いてったりするとまさにその人自身が 例えば単一障害になってその人がこれ言わなくてもいいだろうって思って隠しちゃうとそういう形でいいやその人一方入れただろうってい信頼を失う可能性高いですね。 いや、めちゃめちゃ高いですね。はい。じゃあなんか基本的にさっきの話もそうですけど、色々な人で話し合いましょうねっていうところもそうなんですけど、独人化を解く鍵みたいなところは極力いろんな役割で話すみたいなところが大きいんです。 1 本目としてはそれだと認識します。あの、旧来な何て言われてるかって言うと、 手順化しましょうとか、はい。 こうルール化しましょう。うん。 ドキュメント化しましょう。もちろんやれたら嬉しいんですが うん。 ま、そこが重行長大にできるのはなかなか 1歩目はやはり難しくて、 何もないんだったら、え、チームで話しましょうですね。 具体的にはあのお勧めしてるのはエンジニアチームでその続人化してしまう、ま、もうちょっと言うとベテランですごいできる人が障害対応当たるんですが 分かる。夢ちゃいましたね。わかる。 で、多分八塚さんも絶対電話する人い わかる。1人目が決まってる。 いや、そうなっちゃうんですよね。 で、そのベテランの方に毎週30 分先週来た障害を喋ってもらうっていうのはすごいおすすめです。 あの実はベテランの人がいや、俺に集中してるなって思ってる一方で若手はあ、あの、あの人にお願いしちゃって申し訳ないなって思ってるが大体のチームであります。 で、これ30分に1 回先週起きた障害っていうのをこうそまで喋るだけでいいです。 はい。 あの、何も、えっと、エラーメッセージのじゃ、チケットだけ表示しながら、もしくは何もなければ喋るでもで、それだけで若手は意外に頑張って記録を取ろうとしたり、 じゃ、次これ起きたら何やればいいですかとか。 うん。で、以前1 個面白いノーハウがあったのは、これが起きたら俺に電話してこいって言ってる、説明してる人もいて、ま、それはそれで大事で、例えば 若手が連絡受けちゃったんですが、よくわかんなくてやっぱ怖いんですよね。 はい。 ただ土日曜夜中2 時にこれ電話していいのかなってやっぱ怖くって はいはい ただ俺に電話してこいって書いてあったらけよって言ってたもつってそうすると被害がどんどんちっちゃくなる いやめちゃくちゃ分かるなんか自分が若手エンジニアだった時も はいなんか2 つのことが攻めぎ合ってるんですよね1 つは 任せてもらったから自分がな何とかしなきゃっていうこでなんかよくわかんないちゃんとやらない と1 人前になれないからていうなんか自分を育てようとすることが優先になってしまうっていうこと。 2つ目はそう遠慮はい。はい。 まさに他の人にお願いするの申し訳ないって多分みんなありそうですね。 めっちゃあります。是非 この受け取り手側のそのマネージャーの方とかベテランの方は是非受け入れてあげて欲しくって怒らずに 夜中辛いと思うんですけど受け入れてあげて欲しくてそうすると部下はあかけていいんだで次学ぼうっていう気持ちのいいサイクルに持っていけるんで その重厚調大のドキュメントを作るのがなかなか難しいんだったらまずは 1週間に1 回その遠慮をどう外すかっていうのが あめちゃ大事めっちゃ大事だしこれもうどこの 会社でもできます。 絶対できます。もう来週の定例ミーティングで、え、ベテランの方にいや、俺 24 時間つでも電話していいからて言ってもらえる時すぐ始められます。 あ、めちゃくちゃいい。 それだけで若手がどれだけ救われるか。 確かに。 で、その後その代わり1週間に1 回俺がこう30 分喋るからそれから徐々にできるように1 回起きたねやっぱできるようになってほしい。 うん。 て言うと説明しながら若手は結構必死に。 うん。 それは説明してくれるのありがたいですし、逆にそれが自分たちのノーハウになっていく、能力上がることになってくんで、いい関係が作れますんで、是非やって。 しかも1週間に1 回そうやって話してくれると内容の理解もそうだし、そっからじゃなんか先週起こったのと似てるぞってなったら そうすね。 なんかこれ根本改善しようみたいなモチベーションが全体的に働きそうです。 めちゃめちゃ働きます。 あ、これあ、ベテランのまるまるさん毎週やってるとか思うんで、あ、直さなきゃって思うのもありますし、そこが結構隠蔽されちゃってる。それはベテランの人が気を使ってるんですが、結構すっと解決してるように見えてすごい回数電話受けてたりする。 うん。はい。はい。 それなんかすごいスーパーマンが処理してることが多いんで。 確かに これを明らかにするだけでとてもいい効果あります。 うん。 しかもそれも別に悪気があるわけじゃなくて、あの、自分がやればすぐ住むことだからっていう全意でやってくれてるんだけど、 [音楽] それがじゃあ全体最適になってるかっての話別です。 そんなことないですね。で、どんどんどんどん続人化が強いくような形になってそうなんですよ。 ああ。 で、ベテランはなんで俺だけで若手の人は申訳ないなって変な構造になっちゃうんで。 うん。そしてそこっすね。 それが溜まっていくとベテランが退職して そうなんですよ。 か、体調悪くしちゃうか、 やっぱりこう崩れちゃう 聞いてる中でもこの夜間私も結構しんどかったんですけどやっぱ体病んじゃう人とか うんうんうん。ま、心も体も病んじゃう人 そうすね。なんでで日中体も頑張ってるベテランの人なんでそれをなんとか分散してあげるっていうのは組織としても大事なことかなと思いますね。 うん。 確かに。確かに。そう、そういう意味ではなんかそれその 1週間に1 回話すことが逆にないシーンだと うん。うん。 もう障害応例えば頑張って障害対応マニュアルを作りました。 例えばポストモーテムの仕組みも作りました。 はい。 みたいなのがあったんだけど、もう気づいたらこれこのドキュメント 1 年前のものだから今の機能とか今のプロダクトがこっから 2つ増えてんだけどこっち側ないよねとか 障害対応の設計した内容自体が更新されなそうです。 はい。更新されないです。 あとちょっとこのところの障害対応の改善を私も聞いていて合計 100 社ぐらいとこう意見交換してるんですけどストレートに言うと 初期に作ったドキュメント障害対応ドキュメントはほぼ意味をなしてないです。 チプ化していく チプ化します。で、あれはあれで役割があってこの最初にみんながどういう障害対応のルールなのかなんとなく知るっていう避難訓練的なものとしてはすごい意味があるんですね。 [音楽] はい。はい。はい。 ただ対応時八塚さんも多分 バって障害対応マニュアル開いたことないんじゃないですか? ないす。絶対ないすよね。 で、どんな組織も基本的にないです。 うん。 開かなくてどっちかと基本ルールだけみんなで知った上でそれをこう人間が脳みそに残ったものだけでやっていく はい。 ことになるんでドキュメントを作るよりも毎週こう話してこうが重要になってきますね。 結局ドキュメント書くのめんどくせえつって後回しになって そうすね 頸外化していくって考えるとでもそう考えるとすごく極端話になっちゃいますけどそれが続くともうドキュメント書かなくていいやってなっちゃいそうじゃないですか ああそうですねえっとですね金融とか観光調とかインフラをやっているのは ドキュメントやっぱりいるんですが小規場なシステム最初の頃はまずはないところからでもいいかなと思います。 うん。うん。うん。 で、ただ数人とかの組織だと基本ルールがないと話が通じなくなっちゃうんで、 大きくなってきたらやはりとは思います。 うん。 ただそれも障害時開く用じゃなくてチームに入った人が あ、うちの障害対応こういうルールになってるんだって全体度を掴むレベル なんでマニュアルというにも導入の手引きみたいなもんで はいはいはい。 それ以外はどちらと実践で行われてるものがあって実践値の方が重要は障害時に開ける 1 ページとかを作った方がいいんですが、ま、なかなかいいものはできなくて、 そうするとさっきの30分に1 回実践を学んでいくのが1 番価値が出るってことになりますね。 うん。 なんかそうするとこれまで起きた障害とかは週 1で分かるようになりました。はい。 未知のものに対する設計はどういう風にしていけばいいか? ああ、私は諦めていいと思ってます。 おお。 はい。その心はバリエーションが多すぎてこのモーラをするってのがまず無理だなと思ってます。 うん。 ただ何も手を打たないわけじゃなくて2 つ手を打った方がいいと思ってるのが1 つがさっきと近しいんですがコミュニケーションでマジで分からない未知のものだって時に呼ぶべき人を決めて体制を作る ていうそのルールだけは決めた方がいいです。 うん。うん。 自分じゃわかんないけど未知なのでじゃベテランの誰だ呼ぶ。 うん。 このルールとかあとは組織内とかもしかしたら車内ですごいできる頼れる組織があるんだったらそこへの連絡方法を作っとく ていうのが1つ目。うん。で、もう1 つはえっとこの 著所の中でも書いてるんですけどアクション暫定復旧とか連絡の手順を決めてくってところをですね。 うん。 例えばですが、えっと止まってしまって本当にわかんないけども、ま、とりあえず再起動してみようとか はい。はい。ま、偏してみようとか。 うん。 とりあえずじゃ、この戻しをしてみようとか。 うん。 これも手順を決めとく。やり方を決めといて誰でもできるようにするってのは大事で うん。 で、もし金融とか観光調とかインフラとかこう止まっていて長く続くとどんどんニュースになっちゃうような ところは1 から構築するような手順も準備しといた方がくて ああ、 あの多分バックアップ取ってるけど戻したことないんじゃないかなと思ってて 胸がいて いや、そうなんですよね。あの、大体こうバックアップはなんとなく取ってるんですが戻せないことが多くって でこのうん。 例えばサービスが止まってしまって2 時間ぐらいやってマジでわからんの。 うん。ただあと6時間もらったら1 から作り直して間にあのできるんです。 ああ。 ていうだけでもみんなは安心する。その 最大6時間で済むって分かり。 そうです。そうです。そうです。 で、そうすると大体どういう風な形になるかっていうと、 1 から作り直す手順は以前練習してあって準備できるからそれ確実に走らせてで、もうちょっと早く治るかもしんないからこっちはこっちで走らせてでこっちがマジで分からなかったらしょうがないから 6時間の方に切り替える。 いや、これやれてる人いないな、ほぼ。 あ、これがですね、金融観光長インフラだとあるんですよ。 素晴らしい。 はい。やはりニュースになってしまいますし。 うん。 こう厳しい領域からするとそっちがただそこまでやらなくても最低限再起動とか戻しとかあのそれこそ整ってないもうちょっと警戒なシステムであってもそれをいくつか準備してで うん。そは間違いなくやった方がいいですね。 あとはえっとデータが吹き飛んだ時にちゃんと残るような場所にあるかとか はいはい。 あの、最近のランサムエアで全部 犯かされちゃうとかあるんで、 そこ経由で入ってこれないかとか、ちゃんと隔離する手順とかを準備。さっきのは確かに金融観光みたいな結構大きくて予算があるところじゃないと難しいんですがという、えっと、実証っていうよりもアクションに注目するとやれることは結構限られてきて、 もうちょっと言うと自称、障害対応の自象ってうん。 未知のもの結構多くて わかんないものばっかりだと。うん。 ですが実はアクション、どんな復旧、どんな連絡は意外に選択肢が限られているんで、 確かに その限られた選択肢を準備するっていうのがおすすめです。 なるほど。なるほど。確かにそう考えるとなんか重厚長大なこのケースは 1をやって2をやって3をやって10 をやってみたいな 感じを作るというよりもどのケースでもまずは再起動するとか そうです。そうです。そうです。そうです。 パーツパーツを用意しとくだけだったら確かに誰でもできます。 はい。それがいっぱい1本目ですね。 一旦再起動してって言われるんですけど、 意外にできない人もいて ええみたいな に苦しまないにしたいですね。 はい。はい。確かにね。最近だとクラウドだから再起動しようとしてシャットダウンしちゃうみたいなとか。 そうです。そうです。ただタービスのタービスの順番が実はあってこうやっちゃうとデータベースぐちゃぐちゃになっちゃいますとか が分かってないと怖い。 うん。 それを事前に準備しておくだけでスピードはかなり上がります。 なんかそれで言うとこの設計のところの最後になんかよくあるのが、ま、ちっちゃいサービスとかスタートアップとかだと自社の中でメンバーが全部確立していて で作る人と運用する人が一緒ですていうパターンがあるから、ま、やりやすいと思うんですよ。うん。うん。 一方で結構大きくなるとそもそも開発する人と運用の人別です。 そうですね。 みたいな形なんのにさらに、え、発注元も違います。 はい。開発の会社と運用の会社違います。 なんなら開発の会社ベトナムですみたいな。最近めちゃくちゃ多いじゃないですか。 めちゃめちゃありますね。 こういう時に連絡ってよりなんか抜け落ちやすいかなと思うんですけど。 [音楽] 落ちやすいですね。はい。 どういうところをより気をつけるといいと思いますか?またぐ。 え、またぐまず1 番ベストなのは権限責任専門性実行という 4つを1 つの組織に集めることが重要です。 うん。うん。 何を言いたいかって言うと、先ほどの、えっと、サービス提供の人と運用の人が別れているとどうなるかって言うと、運用の人がやばいから再起動しするんです。やりましょうって言ってサービスの人がそれってどういうことなのと うん。 もしくは連絡つかないと説明してくださいみたいな。 そう、そう、そう、そう、そう。いやいや、ちょっと、ちょっとみたいにな。 私システムわかんないけど説明してください。そうそうなっちゃうんですよね。 で、それを事前に合意しておいて、この範囲まではこうやっても影響ない、 もしくはこのケースの時にはやれますよっていう風に責任を集中してく方が大事です。 うん。 で、そこで、えっと、わざわざサービスに連絡をして承認を取ると遅くなる。 うん。 で、ただ結構できないパターンが多くて、その時にはこのケースの時にはいいでしょって話を事前にしておくっていうものです。 うん。 大体、あの、ちょっと例えば先ほどの動画メディアでサービス提供してて、たまに動画が見えないんですぐらいだったらいいんですが、全然見ればいい。全滅してます。全滅してるのに再起動していいですかってこう聞く。ま、意味わかんない。 ダメなわけねえだ。そう、そう、そう、そう、そう。ただただ結構運用の人真面目な人が多いんで うん。その人に連絡つかないんです。 うん。再できないんでやっちゃうんで、こういう時にはここまでは自分たでやっちゃいますね。こういう時にはここまでオッケーしといてくださいよ。最初に話しとくと実はサービスの人もそこだったらいいよと言ってくれるはずなんですが そりはそう運方はですねんですよ。 これ聞っていいのかなと。ただこんな緊急時のことを兵事に忙しくて聞きたくないだろうなとか 結構恐れてるんです。 その時になったら考えますみたいな。 そうそうそうそうそうて言われんじゃないかと。 うん。 でも意外にこれを我々がめんどくさいからっていう言い方をしちゃう人がいるんですけどサービス全体を守るためにはこの権限いただきたいんですって言ったらおぜ非話そうって言ってくれるじゃないですか。 結構恐れてる人がいるんで、サービス提供側の人には次この動画を見て次みあったら実はそういうので障害対応時検定権限なくて困ってることないって聞いてくれたら実はっていう風に言ってくれたり うん 結構遠慮がちなんでそこをじゃ1 回話してみましょうよとうん 本当に全滅したらどうなりますかってきっかけを与えてくれるとすごい動きやすいんで 是非とも声がけしていただきたいですね。 うん。 いや、確かにな。結局だってそれはユーザーでありサービスのこと考えていいと思ってやってるんだから反対の仕様がないすもんね。本当はね。 ですが、え、言っていいのかな?怖いかなってエンジニア実は思ってます。 いや、分かる。エンジニアもそうだし、さっきの会社とそこに 18発生してるから。 そうなんですよ。はい。 なんか発注元に対してご意見するのはみたいな気持ちになりがち なりがちですね。はい。 でもみんなね、優位サービス作るため運用するためにやってるんだから、それはウェルカムな話ですね。 絶対ウェルカムです。ただそれが分からないんで、運用の人は是ひ言ってみてくださいと。 うん。 で、私は毎回言ってサービスの人にはエンジニアと話してみてください。 で、テレ例でわざわざ1 時間ミーティング作んなくていいんで、テレミーティングのうん。 最後10分でいいんで、 実はそういうのないですかってお互い言うっていうのを 1 回是非この動画を見ていや大事1 回やりたいですね。 大事明日やりましょう。みんなぜひ やってください。明日明日やってください。 明日明日この見て明日1 回そういうの困ってないですかとか定例の枠の中でちょっとこういうの話したいと思ってるんでっていうのをチャット 1 本打つだけでかなり変わってくると思います。 うん。ま、発生しても慌てない。 はい。 え、障害対応の感どっていったところをお伺いできればと思うんですけど、あふしないのどうすればいいですか? ま、あはします。 します。あたふしちゃうもの。うん。 これはもうしょうがない。うん。 ただその中のお守りとして助けてくれる人を作っておく。じゃあ裏を返すと やってはいけないことみたいなところで言うともうわかんないけど自分で抱え続けちゃうことが 1番タブみたい。はい。1番タブですね。 このみに遠慮なく連絡しちゃっていいんで うん。そこを抱えてしまうのが1 番アンチパターンですね。な んでこんな障害を起こしたんだみたいな。 そうですね。 光りつける文化とかがあったら障害が起きた瞬間に また怒られると思って連絡をちょっとしなくなっちゃうとか はい。ありそうだなて。 めっちゃあると思います。少なくとも障害対応時はみんなちゃんと優しく受け入れてあげてほしい。 前向きに障害対応を捉えようとしないと どんどんどんどん悪循環にますね。
チャンネル登録、高評価よろしくお願いします🙇
▼ 後編はこちら (2025/5/29 AM7時 公開)
https://youtu.be/Be11AovARVI
▼ゲスト
野村 浩司 | 株式会社インシデントテック 代表取締役社長
株式会社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:08 ゲスト紹介
03:23 障害対応に注目した背景
06:02 なせ障害対応の設計が重要なのか
07:31 障害対応設計の優先順位の付け方
09:40 ビジネスとの相互理解の必要性
18:34 属人化を解く鍵
26:11 未知の障害に対する設計
18:34 属人化を解く鍵
30:31 分業が進んだ組織での対応方法
35:04 次回予告
#障害対応 インシデント対応設計