【改訂新版】運用設計の教科書 オンライン立ち読み
X（旧Twitter）に投稿した運用設計の読みどころをまとめておきたいと思います。
書店が近くになくて、内容を確認して買いたいけど立ち読みもできないというあなたに向けてお送りします。
運用設計の教科書はサービス導入までに決めることを書いています。
サービス導入後については「運用改善の教科書」を参照ください。
運用を業務運用、基盤運用、運用管理の3つに分類しています。
理由としては、それぞれで設計の型が違うからです。
分けて考えた方が整理しやすくなります。
ウォーターフォールで説明していますが、アジャイルでも最終的な運用設計の内容は変わらないと思います。
アジャイルではリリース後に開発チームが残るので、ゴリゴリに自動化できるところが魅力。
ユーザ/システム、1次対応、2次対応、保守に役割を分けて説明しています。
実際の運用ではもっと細分化することになりますが、要件定義段階では役割を抽象化することも大切。
IPAが出している非機能要求グレード2018は、現時点では運用要件整理の助けになる一番の資料だと思っています。
ただ、そのまま使うのが難しい箇所もあるので補足しています。
運用フロー図を作る基準は、関係者数の多さだと思います。責任者と担当者しかいない場合はフローじゃなくて手順でOK。
運用フローの乱立はルールの乱立を招いて、いずれルールが守られなくなります。
運用設計の虎の巻。
運用項目一覧のサンプル。改訂新版からExcel版をダウンロードできるようになっています。
運用項目一覧をまとめると、何を、いつ、だれが、どのように実施するのか可視化されます。
運用テストの考え方。
運用項目一覧がしっかり整理できていれば、運用フロー図と運用手順書の2つをテストすれば網羅性を保つことができます。
業務運用のシステム利用申請フローの凡例です。
フローではいつ、何を、どのツールで、誰に連携するかを可視化します。
このフローは、ワークフローやITSMツールの基本設計にもなります。
サービスデスクの考え方。
Single Point of Contact（単一窓口）にするべきですが、社内向けと消費者（社外）向けは分けるべきかと思います。
サービスデスクの切り分けフロー。
これは監視オペレータも同じ考えです。
1次対応で解決すると満足度や可用性が上がりますが、すべて解決は無理なのでエスカレーションフローをまとめることも大切です。
パッチ適用のオンプレミスからクラウドの考え方。
クラウドサービスを利用すると、パッチ適用範囲は減りますが、クラウド事業者のメンテナンスを意識する必要が出てきます。
監視の基本的な考え方も整理しています。
インフラ・サービス（アプリ）とセキュリティの3つを解説しています。
システム側の監視と、セキュリティの監視を混ぜると危険です。
改訂新版の追記したセキュリティ監視。
EDR/EPPとSIAMについて解説しています。
アラート検知後に必要なスキルセットがシステム監視と違うので分離がおススメです。
定型・非定型を役割にマッピング。
この考え方は運用改善でも重要になります。
インシデント発生場所に近い人が解決した方が、早く問題解決できます。運用設計はその武器を与えること。
けっこう毎回問題になるログ保管期間の話。
障害対応と監査と訴訟があって、障害対応は90日、監査なら1年以上、訴訟も視野に入れる何ら3年以上がひとまずの基準です。
特権アカウント管理は、個人に権限を付与するのがトレンドです。
このあたりはゼロトラストと関連します。
共有アカウントはブレイクグラスアカウント（緊急アカウント）として残ります。
サービスレベルの基本的な考え方。
クラウドサービスやアウトソースを組み合わせてサービスを提供するので、各所でサービスレベルの考え方も変わってきます。
セキュリティの運用を考えるなら、切っても切り離せないのがCSIRT。
役割分担表と、個別システムの運用体制との関連性をまとめました。
個別システム導入でけっこう迷うことになるBCP/DR。
NISC（内閣サイバーセキュリティセンター）の推奨を元に、全体と個別の話を整理しています。
インシデントのシングルポイント設置のお話。
これはどちらかというと運用改善の要素が強いですが、システム導入時から意識しておくと、リリース後にスムーズに改善活動を実施できるようになります。
定期報告で何を報告するかは、おおよそ定型があります。
改訂新版では、もう大盤振る舞いで報告例を載せました。ぜひ参考にしてください。
最後に参考資料載せました。
運用設計で確認しておいた方が良い資料はここを見れば、ある程度わかります。
どこか興味のある個所があれば、ご購入を検討いただければ幸いです。
この記事が気に入ったらサポートをしてみませんか？