近年における弊社での運用設計に関する考え方について初コラムと綴ってみます。
そもそも運用設計ってなんだっけ？
運用設計は効率的にシステムを運用する、計画や組織を建てつけることです。運用設計はシステムの機能や要件を理解し、それに基づいて最適な運用手順や構成を決定するプロセスです。これには、リソースの割り当て、タスクのスケジュール、監視とトラブルシューティングの手法、セキュリティ対策などが含まれます。
システム品質の向上
システム品質向上の為の取り組みです。稼働率やシステムの性能などに影響と与える取り組みです。
キャパシティの管理
システムのキャパシティすなわち収容量などを管理する取り組みです。特にアクセス数などがシーズンによって変化する場合は大切になります。
構成管理
システムを構成しているパーツ（部品）やバージョンなどを管理する大切な取り組みです。ソフトウェアで言うところのライブラリ管理などに少し似たところがあります。
変更管理
システムに対して変更を行う取り組みを管理する手法であり、システムの障害の大多数はいい加減な変更に伴うものですので、大変大切な取り組みです。
ITILやISO20000だけでは攻めてない
運用設計のガイドラインとしてITILやISO20000があります。これらはシステムの運用を方法を策定するためにあり、システム自体の設計については触れません。DX時代ではITILベースの運用設計だけではなくアプリケーションやインフラの根底からシステム運用を意識した設計や工夫が必要であり、それが不可欠になってきました。
突っ込んだ言い方をすればアプリケーションの設計段階から運用を意識した設計にしていなければ革新的なシステム運用は実現できないと言うことです。
究極は運用しやすいアプリを作るしかない
はい。究極は運用性を初めから考慮しなければ、いつもと変わらない後手に回るシステム運用しか実現しません。
アプリのリリース作業いつまで手作業でやりますか？
不具合、法令対応、その他諸々アプリの仕様変更によるリリース作業は切っても切れない物です。弊社では数年前から標準で自動リリース機能を提案しております。検証環境のリリースはワンクリック、本番環境へのリリースもワンクリックです。（最新のソースファイルをGIT等から取得し、ビルド、デプロイします。）
リリース作業が手作業である限り事故は起こり続けます。
リグレッションテストも自動化しましょう。
リリース作業の自動化と合わせて、ご一緒に提案するしているのはリリース後に行う、リグレッションテストの自動化です。これもリリースや変更によるシステムの不具合を大幅に低下させる重要な機能となります。
障害対応。。。いつまで夜中に起こされますか？
障害対応で夜中に起こされて対応する事があると思います。障害対応も障害の検知から対応までを自動化することで、エンジニアの負担が大幅に減りますし、システムの可用性も大幅に向上します。
ここで出した例はほんの一例です。。。
アプリケーションやインフラの設計時に考慮することで、限りなく手のかからないシステムすることができます。我々はシステムに振り回されるのではなく、DXにつなげるための仕組みを考えていかなければなりません。
最後に
限りあるリソースを有効に活用することが非常に重要になり、システムに振り回されるようなことがあってはなりません。システムを構築する予算に応じて最適なシステム提案が行えると思います。弊社ではアプリケーションの設計段階から運用設計の担当が参画します。そしてお客様に驚いて頂けるようなシステムを納めさせて頂きます。
