以下の記事の内容はすべて私個人の意見であり、所属する組織その他と関係するものではありません。もちろん、内容についての責任はすべて私にあります。

運用を抽象化してドメイン駆動設計できないか？

なにを突然言い出すのやらですが、SIerの顧客システム運用（またはIT運用：以下、運用と記載）をドメイン駆動設計してみたらどうだろう、というポエムです。

泥臭い運用をオブジェクト指向プログラミングの意味で抽象化できれば、

• 顧客の価値を中心に運用をモデル化できるのではないか？
• 安定稼働と変化を濃淡も持たせて両立させるモデル化ができないか？
• 運用のロールとヒトを切り話したモデル化のあとでヒトの配置を検討できるのではないか？

というのが、中心的なアイデアです。

SIerの伝統的なシステム運用

まずは、なぜそんなことを考えてみるのか？　その背景について、長くなってしまいますが、もしよければおつきあいください。

伝統的な話にはうんざりという方は、続きのこちらへ。
システム運用のドメイン駆動設計、または運用の抽象化（「ドメインを隔離する」）

SIerがアジャイル開発&DevOpsする風景をポエムにしてみました。
SIerの生き残り戦略としてのDevOps　システム運用の社葬から

運用の範囲・対象

運用の定義の混乱

システム運用とは
Wikipedia日本

システム運用（-うんよう）とは、コンピュータシステム等のシステムが停止することなく、利用顧客に対してつつがなくサービスを提供できるよう当該環境を維持管理すること。

うーん。英語だと...。

Information technology operations
Wikipedia

Google先生通訳

IT運用の定義はIT 業界全体で異なります。ベンダーや個々の組織は、自社製品のマーケティングを目的として、そのようなプロセスやサービスの独自のカスタム定義を作成することがよくあります。運用作業には、保守作業または顧客の問題のために生成されたチケットへの対応を含めることができます。チームはイベント監視を使用してインシデントを検出できます。多くの運用チームは、勤務時間外のインシデントに対するオンコールの対応に頼っています。IT運用チームはソフトウェアの展開と保守運用も実施します。

なんか泣けてきた...。

定義
Joe Hertvik氏は、IT運用を「ネットワークインフラストラクチャ、サーバーとデバイスの管理、コンピュータの運用、ITインフラストラクチャライブラリ（ITIL）の管理など、社内外の顧客へのアプリケーション展開をサポートするインフラストラクチャと運用環境の円滑な機能を担う」と定義しています。そして組織のためのデスクサービスを助けてくれ」

助けてくれと言われても...。
さらに、

Gartnerは、IT運用を「適切なサービスを適切な品質と競争力のあるコストで顧客に提供するためのITサービス管理に関連する人員と管理プロセス」と定義しています。

IT運用は通常、ソフトウェア開発とは別の部門と見なされています。「ネットワーク管理、デバイス管理、携帯契約、あらゆる種類のヘルプデスク」などが含まれます。

アーネストミューラー氏は、IT運用を「システムエンジニア、システム管理者、運用スタッフ、リリースエンジニア、DBA、ネットワークエンジニア、セキュリティ専門家、その他さまざまな分野および職種の総称」と定義しています。

というわけで、運用の定義のこの混乱ぶりが、その不可解さ、泥臭さの根本にあるわけです。

つまり、

• 範囲
  • とにかくITが関係するところなら全て
• 対象
  • モノ
  • ヒト
  • サービス
  • プロセス（ISO9000の意味で）
  • その他、ITが動いたり動かしたり動かなかったりするもの全て

であり、運用とは「とりあえず運用でカバーすること」と定義されます。（再帰的定義）

運用の目的

概ね下記ではないでしょうか。（RASIS無視）

• システムの安定稼働
  • 堅牢性（落ちない）
  • 冗長性（落ちても切れない）
  • 保守性（切れてもすぐ復旧）
• 情報セキュリティ
  • 機密性（情報に勝手にアクセスできないようにする）
  • 完全性（情報を破壊や改ざんから完全な状態に保つ）
  • 可用性（情報にいつでもアクセスできるようにする）

もちろん、いまでも、SoRとかエンタープライズとか言われるシステムの最大の目的。

ところで、相反するように言われる

• サービスの迅速で継続的な変更

という目的が、とくにSoEと言われるWebサービスを中心としたシステムでDevOpsというカルチャーと合わせてクローズアップされてきたという理解です。
が、これらは本当に矛盾する目的なのか、というのが、この「システム運用のドメイン駆動設計」を書いている一つの動機です。

単純に、こんな風に項目立てしてみたら、そんなに違和感はないのではないか？

• 事業継続性
  • システムの安定稼働
  • 情報セキュリティ
  • サービスの迅速で継続的な変更

とりあえず、伝統を先に続けます。

運用設計

運用を設計するフレームワークとよくある内実について。

ITIL

ITILはとてもいいことをたくさん書いています。
もちろん、運用のドメイン駆動設計にITILを利用しない手はないですから、ここで少しだけITILの功罪について私見を書きたいと思います。

いわく、

• サービスとは、顧客が特定のコストやリスクを負わずに達成することを望む成果を促進することによって、顧客に価値を提供する手段である。
• 価値とは有用性と保証で構成されている。

としていて、有用性と保証のITサービスマネジメントのベストプラクティスを記載してあるという理解です。

ただ、ITILは、基本的に個別の顧客にとっての価値を提供し続けるための方法論であり、サービスプロバイダは顧客ごとに「いま何を価値としているか」「今後は何を価値とするか」をもとに、個別の戦略とデザインから始めること（個別最適化）を前提していると思います。

これは、複数の顧客を１組織でマネージメントするサービスプロバイダであるSIerにとって、運用（設計）の再利用可能性がどうしても低くなってしまう点に問題があります。
それでも再利用しようとすると、なんとなく網羅的で美しい「形式主義」に傾いてしまうこともありがちです。

また、そもそも、ITILは「運用」ではなく「ITサービスマネジメント」のベストプラクティスだと思うのですが、

サービス（ITサービス）のうち、「運用（サービスオペレーション）」は「顧客に価値を提供する手段」から切り離され「顧客が特定のコストやリスクを負わずに達成する」ためのITリソースや能力を維持することであると受け取られがちです。

または、この裏返しですが、ITIL全体が「運用サービスマネジメント」であるという拡大解釈もよくあり、「運用サービス」だけを切り離してコストと天秤にかけ、価値が過少であると受け取られることもあるあるです。たとえプロジェクト（プロダクト）全体のサービス価値を下支えしているのが運用であるとしても、です。

運用の定義が曖昧なまま、ITILだけが独り歩きしてしまうのがいけないのではなかろうかと思います。

ITILコアドキュメントが最初に自分で言っているように、価値を決めるのは顧客ですから、すべては顧客に価値を認めさせるサービスを「運用」自体が提供できなければいけないということであろうかと思います。

宮大工

案件受託型の運用設計を一口でよく表している表現ですが、その特徴は、以下のようなものかと思います。

• 宮遣いと現場
  • 顧客や上層部に納める設計書はとてもよくできているように見える
  • 設計現場（顧客含めた担当）は、現実と乖離した設計方針を全然見ていない
• 経験と勘
  • 「そこはズバッとやってあとでパパッとやればぴったりするんだ」
  • ぴったりすることもかなりあるが再現根拠がない
• 大工は建てるのが仕事
  • 「さあ次の現場だ」
• 徒弟制
  • うまくやれた人や方法の真似をする
  • うまくいく場合もかなりあるが再現根拠がない

といった感じで、まとめると、

• 形式主義
  • とてもきれいなフォーマットを埋めるとなんとなく素晴らしい設計ができているように見える
• 非再現性
  • 設計者が優秀だとうまくいく。うまくやれたことはあまり言語化されない
  • 現場の設計者がパパッとやったことがうまくいったという評価は建立時点で終わり
  • 建ったものがどんどん湿気で傾いていってもそれは建物の管理者責任になる

の2つが大きな特徴かと思います。

運用実施

では、一般的に伝統的なSIerの運用はうまくいっていないのだろうか？

運用受け入れ

運用設計現場がパパッとやったものが本当にうまくいくのかは、運用を受け入れる側に責任がある。
それゆえに、受け入れ基準を設けるのだが、

• 設計がきれいに見えて、ドキュメントなどのモノがそろっているならば受け入れない理由がない
  • 大規模であればあるだけモノは大量にある
• 実機で受け入れ引継ぎをやってもらえないことがあるある
  • スケジュール押し
  • プロジェクト最終盤で本番構築後なので、そもそも手順書通りやってはいけない運用作業（移行済みDBをリストア・リカバリするとか）

結局どれほど経験を積んだ運用者でも、そもそもの設計が合目的的か合理的かは実際に運用を始めないと完全にはわからない、ことが多いのではないでしょうか。

個別最適化によるハイパフォーマンス

顧客と直に接するのが運用現場であり、要望に応えて顧客の満足度を上げるのは運用現場。

• カイゼンという名の家内制手工業
  • できる範囲でなんとかせざるを得ない
    • けっこうできる（達成感がある）
    • 顧客にうけがいい（達成感がある）
• 他の顧客運用チームや組織を超えた情報を「見てはいけない」というセキュリティ基準（NDA）の壁
  • 車輪の再発明と顧客の業務要望に沿った線路の敷設
    • ハイパフォーマンスの実現（達成感がある）

属人性によるハイパフォーマンス

運用のスパンは長い。同じ人が10年なんてのは当たり前の世界。

• 顧客とあうんの呼吸でコミュニケーションできるようになる
  • 顧客担当者に頼られる（自己承認欲求の充足）
• 顧客側の担当者が交代していく
  • 運用者の有識者化（自己承認欲求の充足）

「自分の居場所はここなんだ」という多幸感と、異動した場合の自分の価値への不安が属人性に拍車をかける。

• 「自分にしかできない仕事」を作ることが目的になる
  • 局所的なハイパフォーマンスの実現（自己承認欲求の充足）

伝統の限界

それで？　ハイパフォーマンスな職人の伝統芸でなにがまずいのか？　

運用のコストセンター化

• 運用のブラックボックス化
  • 費用対効果の説明が困難
  • 顧客の不信感の増大
  • 競合アウトソーサーや黒船クラウドの忍び寄る影

これではいかん。顧客に納得してもらわなくては。ならば、

• 工数の見える化でコスト適正を主張しよう
  • コスト削減圧力
  • 顧客にとっての価値を削る
  • 顧客満足度低下
  • コスト削減圧力
  • 顧客にとっての価値を削る
  • 顧客満足度低下
  • コスト削減圧力

…デススパイラル

そうじゃない！

「運用の顧客価値を見える化したい」

運用の保守化

conservativeの方の保守化ですが、

• 安定稼働の最大価値化

  • 過失障害「0」の目標
  • セキュリティインシデント「0」の目標

• 自分でコントロールできる（理解できる）範囲に絞って実施し、自信をもってできること以外には手を出さない

  • 本番変更作業を嫌う
  • 新しい技術に懐疑的になる
  • 慣れた運用からの変化を嫌う

結果、運用者個人への顧客評価とは逆に、運用チーム全体としては顧客の事業戦略変化についていけない組織となりがち。

そうじゃない！

「運用現場だからこそ安定稼働と変化の両立に貢献したい」

スキル・ロール

運用者の伝統的ロールと問題点はこんな感じでしょうか。

• オペレータ
  • 定型的な作業／WhyのないHowのみの手順書
    • 経験が積みあがらない
    • モチベーションの低下
    • 経験が積みあがらない
    • モチベーションの低下

　　…デススパイラル

• 運用SE（業務運用）
  • 顧客依存の属人的な運用によるハイパフォーマンスが存在理由
    • 顧客の業務ルールに精通
    • 引き継げない・引き継がない
    • 異動できない・顧客も異動させない

　　熟知した顧客ルールやツールや製品でないと運用できない（かもしれない）。個人のスキルパスの欠落リスク。

• 運用SE（インフラ運用）
  • 技術依存の属人的な運用によるハイパフォーマンスが存在理由
    • 特定のインフラ技術に特化したスキル
    • 引き継げない・引き継がない
    • 異動できない・顧客も異動させない

　　特定のインフラ技術に特化したスキルでインフラエンジニアへシフト（正当なスキルパス）。運用チーム内の必須ロールの喪失リスク。

そうじゃない！

「運用のロールとヒトを切り離したい」

では、運用を抽象化したら？

で、最初に書いたように、おおよそこんな背景で、泥臭い運用をオブジェクト指向プログラミングの意味で抽象化できれば、

• 顧客の価値を中心に運用をモデル化できるのではないか？
• 安定稼働と変化を濃淡も持たせて両立させるモデル化ができないか？
• 運用のロールとヒトを切り話したモデル化のあとでヒトの配置を検討できるのではないか？

と考え始めたわけです。
前置きが長過ぎました。ポエムですので今すぐ何かの役に立つわけではないですが、アイデアの足しになれば幸いです。出来れば続けたいと思います。