稼働した翌日から、設計の結果が現れる

架空事例：青葉機材の予約システムが本番稼働した後の運用を考える。障害・教育・効果測定の条件は架空のもので、特定事業者の実績や実運用手順ではない。

サーバは正常で、予約ができない

新システムは予定どおり稼働した。監視画面のサーバ稼働率は正常で、DBへの接続も成功していた。それでも取引先は予約を完了できなかった。

契約条件を確認する外部サービスの応答が遅く、受付がタイムアウトしていたのである。利用者にとっては予約できない状態だが、プロセスは正常に動いている。何を「サービスが稼働している」と呼ぶかで、観測する指標が変わる。

運用の準備は、監視ツールを配置することだけではない。業務のどの結果を継続し、障害時に何を保留し、誰が判断するかを設計する。シラバス16-2、18-1、19-1は運用方式とシステム・業務運用の評価を別々に扱っている。1

運用テストが見ているもの

開発環境では予約登録のテストが通った。しかし、本番の監視、バックアップ、ジョブの起動・停止、障害連絡、利用者からの問い合わせ対応は十分に確かめられていなかった。

システムが仕様に適合しているかと、運用者が実際の環境で必要な手順を実施できるかは別である。運用テストの計画では、通常運転だけでなく、予定停止、異常終了、復元、旧システムとの切替え、運用者の作業も対象になる。

バックアップを取れたという報告だけでは、実際に戻せるか分からない。どの時点のデータへ戻り、どの業務を、どの時間内に再開できるかを、設計で定めた条件へ照合する。

リハーサルで手順が失敗したら、手順書を改めるだけでなく、復旧のための環境や権限が不足していないかを調べる。操作を間違えた個人の問題として片付けると、次の障害で繰り返す。

障害対応と問題管理は、時間軸が違う

サービスが止まった。まずは利用者への影響を制限し、復旧を進める。その場で原因を完全に特定できるとは限らない。復旧後には、再発を防ぐための原因分析と変更が必要になる。

即時の復旧と、構造的な原因を除去する改善を分ける。例えば外部サービスが不応答の間、必要な受付を保留する暫定運用は有効かもしれない。だが、タイムアウトが一つの呼出しへ集中している設計を改めなければ、同じ問題は残る。

障害件数を減らすことと、利用者にとっての停止時間を減らすことも同じではない。短い障害が多い状態と、長い停止が一回だけ起きる状態は、同じ件数では比較できない。影響を受けた業務と時間を合わせて評価する。

Google SREの公開資料は、内部の測定と利用者から見た振る舞いを区別し、監視を障害への対応へ結び付けて考える。2 ここではGoogleの推奨値を青葉機材のSLAへ無条件に適用するわけではない。

変更するなら、何を壊す可能性があるか

営業の要望で予約条件を一つ追加した。条件式の変更は小さい。ところが、料金計算や出庫予定、請求書へ影響するかもしれない。

変更管理は、承認するための会議を増やすことではない。どの要求へ対応し、どの機能とデータが影響を受け、どの検証が必要になるかを追跡することだ。原教材のトレーサビリティの考え方が、稼働後にも使われる。1

修正後に以前の機能が壊れていないか確認する回帰テストと、変更した仕様が正しく動くか確認するテストは目的が異なる。また、実行環境へ適用した版と、検証した版を混同してはいけない。

障害時に旧版へ戻す案があっても、新版で作ったデータへ旧版が対応できるとは限らない。プログラムの切戻しと業務状態の復旧を一つに書かない。公開判断の時点で何を取り消せるかを考える。

教育は、使い方を知らせること以上の仕事

新しい予約画面の説明会を開いた。出席率は高かった。しかし営業担当者は、例外の予約をどう扱うか理解していなかった。

教育資料を配布した事実と、必要な業務判断を実施できる状態は違う。利用者、運用者、保守担当者それぞれの作業と権限に合わせて、習得すべきことを定義する必要がある。

青葉機材では、標準の予約を登録するだけでなく、点検未完了の機材が要求されたときの判断、顧客へ誤った案内をしたときの訂正、外部サービス停止時の連絡を、実際の手順に沿って確認する。

誰に何を教えるかは、業務と責務の分割に依存する。運用担当者に営業の値引き承認の判断を押し付けても、統制は成立しない。シラバス4-13も教育訓練の目的、対象、体制、時期を計画する活動を扱う。1

受入れの合格と、利用時の成果

仕様書にある機能がすべて動き、受入れを終えた。これは重要な区切りである。しかし、業務が効率化されたかという問いへの答えとは違う。

システムへの要求への適合を確認するVerificationと、意図した用途で必要を満たすかというValidationは対象が異なる。NASAのシステム工学の公開解説もこの二つを区別する。3 ただし宇宙機の認証手続を一般の業務システムへそのまま移すわけではない。

例えば予約画面の応答は二秒以内でも、営業が三つの画面を行き来して手作業で確認するなら、受付完了時間は短縮しない。運用開始後の利用状況や業務効果を測定し、当初の目的と比較する。

保守は修正だけではない

OSの更新でアプリケーションが動かなくなる、外部サービスのAPIが変わる、取引先の業務規則が更新される。いずれも開発時の仕様から環境が変化する出来事である。

保守には、欠陥の是正、環境の変化への適応、改善、予防的な変更が含まれる。変更の優先順位を決めるとき、影響する業務、必要な停止時間、費用、検証の範囲を考える。

保守作業のたびに属人化した手順へ頼るなら、設計やドキュメントの不備が隠れている可能性がある。運用から得た情報を次のシステム方式へ戻すことは、欠陥の修正とは別の価値を持つ。

運用を測ることが、次の企画を生む

稼働後半年で、営業の受付時間が短くなった。ただし顧客満足は変わらず、返却後の点検待ちが増えていたとする。改善した領域の外に、次の制約が現れたのである。

効果測定は成功報告のためだけに行うのではない。どの処理が律速になり、どこへ新しい課題が移ったかを見つける。シラバス20-1は投資効果・業務効果の実績を、次期システム方式やビジネスモデルの企画へフィードバックする能力を扱う。1

運用と企画は、開発の前後に分離した世界ではない。業務の目的に戻って評価するとき、運用で見つかった事実が次の要件定義を形づくる。

知識を答案へ戻す

午前Ⅱ。 運用テスト、システム適格性確認、受入れ、変更管理、回帰テスト、保守の種類を区別する。

午後Ⅰ。 監視がどの状態を検知できるか、どの業務が停止するか、誰がどの手順で復旧するかを問題文から読み取る。

午後Ⅱ。 方式を導入してからの運用条件、障害・変更時の判断、教育、効果測定を、採用理由とともに説明する。

立ち止まって考える：サーバが稼働し、監視も正常なら、運用設計は成功したといえるか

利用者の重要な業務が完了できるか、依存先の停止や復旧時に何を継続できるかを別に確認する必要がある。内部の監視値だけでは業務結果を保証できない。

出典と照合範囲

[1] コンプリートテキスト第2・8・10・11・13・25章、IPA SAシラバスVer.5.2：運用テスト、保守、品質と事業効果の評価を出発点とする。公式シラバス

[2] Google, Site Reliability Engineering, Monitoring Distributed Systems：利用者から見た振る舞いと内部監視を区別する考え方を参照した。公開本文

[3] NASA Systems Engineering Handbook, Appendix D/E：VerificationとValidationの目的、要求と確認方法の対応という考え方を参照した。特定の宇宙機の制度を一般の業務へ転用しない。公開解説