障害を発生させないために

障害を発生させないために @s_tanaka

アジェンダ そもそも障害ってなに? なんで障害は発生するの? 障害を起こさないために何をすれば良いの? 障害が起きたときどうすれば良いの?

障害とは? システムの構成要素であるハードウェアの故障、ソフトウェアのバグやその他の機能不全が原因となって、システムが本来の機能をユーザに対して提供できない状態を言う。（Wikipedia 「障害 -情報技術分野での障害(Fault)」）システムが仕様（思い）通りに動作しないこと ※仕様が間違っている場合もある…

発生する要因 コミュ不足 作業ミス ハード故障 運用 バグ 仕様漏れ テスト不足 不明どっかで見たこと
あるぞ? AAのインシデント管理システム

テスト不足発生した要因で一番多いのが「テスト不足」 そもそも試験しなかった 試験したけど不十分だった（パターンから漏れていた） そんなところに影響があるなんて思わなかったバグ + テスト不足と言うのも多い →バグがあってもテストをちゃんとやっておけば気付けた
なぜテスト不足が発生するのか

気づきのポイント要件定義 •要件定義書設計 •設計書実装 •コード試験 •試験仕様書リリース
•リリース手順書各工程で漏れがなければ障害の発生はかなり抑えられる →それぞれのOutputをチェックすることで、その工程は（ある程度）担保される各工程と成果物（Output）

がしかし… 今まで要件定義設計実装試験リリース 1人日 1人日 3人日
1人日 0.5人日計6.5人日全部やると要件定義設計実装試験リリース 1人日 1人日 3人日 1人日 0.5人日計11.5人日 0.5人日 ×2 0.5人日 ×2 0.5人日 ×2 1人日 ×2 0.5人日 ×2

なのでプロジェクト全体の大きさに応じて各工程のアウトプットの有無、レビューの有無を決めよう。 …それだと、いつもと変わらないので、試験仕様書の作成と、それの確認を行ってはいかがだろうか。ライトな開発でも、行った動作確認の流れや、画面表示があればキャプチャを貼るなどで、確認項目の共有（他の人がわかりやすい）や、自分自身での確認、今後同様の開発があった場合の注意点となる。

テスト不足になる理由要件定義設計実装試験リリースリリースまで時間が無く、実装を進めながら仕様の調整、試験と言うよりは動作確認のみになってしまう場合が多い（気がしている）。コードレビューは行っているが、それだけではそのシステムに詳しくない限り、潜在しているバグや仕様漏れに気付くのは難しい（私だけ?）
バグを発見する可能性で言えば試験が重要 →テスト不足の障害が少なくなるのでは?

障害は発生する気を付けていても予期せぬ要因で障害は発生する障害が発生しないようにも重要だが、障害が発生してからの対応も重要。

障害が発生したら暫定対応? 状況の確認障害発生関係者に連絡暫定対応内容の検討暫定対応
解消? Y N 恒久対応内容の検討 N Y 恒久対応解決? 関係者に連絡 N Y インシデントレポートインシデントレポートは社内で共有

障害の報告第一報には下記をわかる範囲でまとめる 発生事象 発生日時 （判明していれば）原因 （わかっていれば）解消予定時間事象が解決したら、下記も調べて報告する 発生期間 影響範囲 対応内容
上記にプラスして、インシデントレポートでは再発防止策があれば記載する

最後に障害は時間が無い場合に発生する。時間が無いと、試験の時間を削ってしまう場合が多いから。時間が無いというときは、危ないなと思い、実装だけじゃなく、試験の時間も確保出来るようにしましょう。試験仕様書は、作成することで、パターンの洗い出しや、実装の漏れに気付く場合もあるので、未知なるアプリ、機能の改修の場合、文字に起こして整理することが大事。共有されたインシデントレポートから、障害になりやすい内容についても試験を行うことで、より障害の発生の可能性を下げられる。チームで障害が発生しない仕組みを考えましょう。
試験仕様書（をはじめ、ドキュメント類）は標準化し、作成のコストを抑えたい

障害を発生させないために

障害を発生させないために

s_tanaka

Other Decks in Education

Featured

Transcript