運用設計重要度ランキング
運用設計には優先すべき項目がある。
運用設計は取捨選択の連続です。
なぜ取捨選択するかというと、別に運用設計してなくサービス提供できるからです。
たしかに運用しながらブラッシュアップしていった方がよい運用項目もあります。
自動化なんてのはその最たる項目な気がします。
運用設計に取捨選択を迫る要因としては、予算や運用体制、プロジェクトスケジュールなどはもちろん、システムを導入する企業や利用者のITリテラシーなどもあります。
何かの理由で優先度をつけて運用設計をしなければならない場合、いったい何から手を付けるべきなのかを考えておいた方が良いな、と思い立って「運用設計重要度ランキング」を作成してみました。
検討に使った指標は以下の3つです。
運用設計しなかった場合のリスク（個人的な感覚）
参考書の出版件数
非機能要求グレードの該当数と重要項目数
PDFにまとめてみたので、ご興味のある方はダウンロードしてみてみてください。
それでは、ランキングを少し解説してみます。
１位 システム利用に関する申請（業務運用）
なにはともあれ、システムを作っても使えなければまったく価値がありません。
そもそもシステム利用に関する申請業務は、非機能要件ではなく機能要件です。
なにをおいても、まずはシステムを使うための動線を整理して、必要ならユーザーからの申請や権限付与などの作業をまとめるべきです。
これは、ダントツの１位でよいと思います。
２位 セキュリティ運用
セキュリティ運用は近年順位を上げてきた感じです。
システムが使えても、情報を垂れ流してしまうような仕組みだと安心して使えません。
非機能要求グレードには6つの分類があるのですが、その中にズバリ「セキュリティ」という大項目があります。
参考書出版数も他の運用項目と比べものにならないぐらい膨大です。
このあたりの「機能」と「セキュリティ実装」は、間に合ってないとリリースが延期されることもあります。
また、企業規模が大きくなればなるほど重要視させる項目でもあります。
３位 監視
昔から運用といえば監視です。
監視は障害のトリガーになるため、アラート検知できないということは、勝手にシステムがとまるということです。
参考書出版数もそれなりにあり、非機能要求グレードもそのものずばり「監視」というキーワードで重要項目があります。
システム監視とセキュリティ監視に分かれていて、監視対象と対応は違うのですが、どちらも障害や不正検知のトリガーとなっていることは変わりません。
できるだけリリースまでに実装して運用開始しておきたいです。
というか、できればリリース前１か月ぐらいまでには運用テストで監視できることを確認しておきたい項目です。
４位 バックアップ
バックアップも古くから運用に紐づいている項目です。
バックアップデータが取れていないことは、有事の際の死を意味します。
私、ミスしないので。ならバックアップしなくてもよい気がしま・・・、あ、ダメだ、自分がミスしなくても誰かがミスするかもしれません。
バックアップは製品によるところなので、参考書籍はあまり出ていませんが、非機能要件は「可用性」「性能・拡張性」「運用・保守性」「セキュリティ」と４分野が該当します。
とにかく何かあった際のお守りとして、バックアップを設計する必要があるということです。
こちらは構築時に合わせてバックアップ設定なり、バックアップの仕組みを構築しておくのが一般的ですので、リリース時のバックアップが取れていないことが発覚したら、もう、なんというか、アレですよ、アレ。
５位 運用アカウント管理
システムの運用する際にどのようなアカウント、権限が必要かをまとめて、運用者の入れ替え時の対応をまとめる業務です。
運用アカウント管理は、広義ではセキュリティ運用の一環でもあります。
セキュリティには「最小の範囲に最低限の権限を付与する」という考え方があります。
しっかり設計するとけっこう時間がかかるのですが、ざっくりやるなら運用者に高権限をバンバン振っておけばなんとかなります。
あと、永遠に人の入れ替わりがないなら適当にやっておいてもOKです。
運用アカウントというキーワードの参考書はないのですが、認証システム（AWS IAM,AD/AAD,Oktaなど）の一部なので、それらの参考書はかなり出ています。
非機能要件としては、サポート体制やアクセス制限といったところが該当します。
こちらもできればリリースまでに設計しておきたいですね。
６位 パッチ適用
バグや脆弱性、機能追加などの対応を行うための運用項目です。
こちらも広義ではセキュリティ運用の一環です。
リリース直後はほっておいても大丈夫です。ただし、そのままほっておいて何か重大な脆弱性を攻撃された場合、運用者として言い訳が苦しくなります。
パッチ適用も製品によるところが多いので参考書はそれほど出ていません。
非機能要件には「パッチポリシー」と「セキュリティパッチ適用」が該当します。
リリース時に間に合ってなくてもよいけど、リリース後の早い段階でルールを決めて運用を開始する必要があるでしょう。
７位 保守契約管理
システムに導入しているサポートの情報をまとめて、運用者がスムーズに問い合わせできるようにしておきます。
製品数がすくないから、別にまとめなくても製品の契約書を直接見るから大丈夫というという場合もあります。
また、運用者が日本トップクラスの製品スキルを持っているから、サポートに問い合わせしないなら大丈夫です。
非機能要件は主に「保守運用」「障害時運用」といったところが該当します。
特にオンプレ機器がある場合は、シリアル番号なども含めてしっかりまとめておいた方がいいでしょう。
リリース時にまとまっていればベストですが、保守契約さえ結ばれていれば
あとでまとめるでも問題ないと思います。
８位 ログ管理
障害系のログは監視である程度確保できていて、ログの保管期間はセキュリティ運用で担保されているという前提でこの順位です。
監査などの対応のためにシステムのどこにどんなログが確保されているのかを把握しておくのは重要です。
それはそのまま、障害対応の原因究明スピード向上にもなります。
近年はビッグデータという観点でも、ログの保管が重要になってきています。
ただ、運用という観点だと監視が出来ていて、ログ保管期間がセキュリティルール通りなら、情報のとりまとめリリースに間に合ってなくても、という感じはあります。
９位 自動実行処理管理（アプリ除く）
単純な運用作業を自動化した際の管理です。
自動化した作業エラーが監視で検知できる状態なら、情報のとりまとめを急ぐことはありません。
リリース後にも運用設計する時間がありそうなら、忘れないうちにまとめておこう、ぐらいの気持ちでも大丈夫です。
この分野は参考書籍はたくさんあります。
ただ、運用作業効率化というよりは、業務効率化での書籍が多いですね。
逆に非機能要件は「障害復旧自動化の範囲」のみです。
運用業務の自動化は、運用設計というよりは運用改善なので、リリース後にやっていきましょう。という感じだと思います。
まとめ
なにか抜けている気もしますが、主要な運用設計項目についてはまとめられたとおもいます。
「バックアップよりパッチ適用の方が大事だろ！」「なんであれが入っていないんだ！」等々、いろいろ思う所はあると思いますが、これを眺めながら運用設計に少しでも想いを馳せてもらえればと思います。
=================
システム運用設計と運用改善についての本を出してますので、ご興味ある方はぜひ読んでみてください。
また、ITシステム運用に関するセミナーやワークショップもやっていますのでご興味のある方はTwitterかFacebookにご連絡ください。
この記事が気に入ったらサポートをしてみませんか？