【第15回】システムは「作って終わり」じゃない——運用の話

それ、実は逆なんだよね。完成してからが本番

家も、建てて終わりじゃなくて、そこから住み続けるでしょ。掃除も、設備の点検も必要。システムも同じで、完成後にちゃんと運用し続ける仕組みが必要なんだ

システムを安定的・効率的に運用し続けるための一連の管理活動をITサービスマネジメントと呼ぶ。この考え方の土台になっているのがITIL（Information Technology Infrastructure Library）、ITサービスマネジメントのベストプラクティスをまとめたガイドライン

『こうやると上手くいきやすい』っていう、業界で積み上げられたノウハウ集、というイメージでいいよ

あと、第11回で出てきたSLA、覚えてる？　『稼働率99.9%以上を保証する』みたいな約束の文書

そう。SLAは結ぶこと自体がゴールじゃなくて、結んだ約束を実際に守り続けることが本番。だから運用の仕組みが必要になる

運用の現場でよく出てくるのが、この3つ。インシデント管理、問題管理、変更管理

1つずつ整理しよう。インシデント管理は、実際に起きたトラブルに対して、とにかく早くサービスを元に戻すための応急対応。原因の追求より、まず復旧が優先

いい例え。それに対して問題管理は、そのインシデントがなぜ起きたのか、根本原因を突き止めて再発を防ぐための活動。応急処置じゃなくて、火種そのものを取り除く

そのとおり。最後、変更管理は、システムに変更（アップデートやパッチ適用など）を加えるとき、それが新たなトラブルを生まないよう、あらかじめ承認プロセスを通して安全に反映するための仕組み

うん。変更管理をすっ飛ばして本番環境をいじると、それ自体が新しいインシデントの原因になりかねない

あと、システムを支える物理的な設備——データセンターの電源、空調、セキュリティなどを管理するのがファシリティマネジメント。システムそのものだけじゃなく、それを支える"箱"の管理も運用の一部なんだ

1つ目は、インシデント管理と問題管理の目的の違い。『応急処置か、根本解決か』、この軸で見分ける

変更管理の承認プロセス。『誰かが勝手に変更していい』わけではなく、あらかじめ決められた手順を経て反映する、という前提が問われやすい

じゃあ次は、その運用がちゃんとできているかを"チェックする"側の話。監査って聞いたことある？