DevBizOpsとCPU増強の費用対効果
今週初めに問合せ対応で「CPUリソース増強の費用対効果」を相談された。その時考えたことが、一昨日のAWS Innovate Modern Appication Editionのオープニングセッションで話されていた「DevOpsの共通言語づくり」「メトリクスをBizも関与して決めていく」ということと同じというか、表裏の関係だと気づいた。そんなDev・Ops・Bizで決める監視項目の話を書き留めておきたい。
CPUリソース増強の効果って…
ある社内システムの運用部門から、こんな相談があった。
社内システムの無応答が昨年来報告されている。
原因究明に至ってないが、調査できたタイミングでは特定プロセスがCPU使用率100%になっており、それが20分後に自動再起動されて復旧した。
追跡調査で、無応答時にCPU飽和してることが多いことは確認している。
直近半月のモニタリングでCPU使用率95〜100%が5回、業務時間中に確認されている。
利用者数は800人/日程度で増減していない。
そしてCPU増強（EC2インスタンスタイプ変更）をサービスオーナーに申請しているのだけど、そちらでの上申に説得材料が不足ということでずるずる先延ばしになっている、費用対効果を示したく何かヒントはないかということだった。ここまでわかっている人ならば費用もわかっているだろう。多分、効果を示せないのだ。原因究明できてないから、CPU増強で解決の見込みが何%あるかとか、その確度を測る方法はないかとか。迷路にハマってるのだなと思うけど、そんな迷路、そもそも入るべきじゃない。
ITの『効果』はビジネスインパクトで量る
僕が追加ヒアリングをしながら返した応えは、こんなものだ。こんな立て板に水の問答じゃなくもっとたどたどしくだけど、だいたいこんなことを伝えたと思う。
「まず社内システムといえば生産性向上か収益拡大のためですね？これは？なるほど、生産性ですね。」
「半月で5回なら、月間だと10回程度CPU飽和してそうですね。20分で自動復旧だとすれば月間累積200分。月間の勤務時間は160時間が基本であってますか？だとすればその2%ぐらいですね」
「毎日800人が利用なら、このシステム無応答が800人の業務を止め、800人の生産性を2%損なっている推計になりますね。費用対効果の『費用』はAWSのランニングコスト増と作業のイニシャルコストです。でも『効果』はこの生産性影響、これがサービスオーナーにとって一番大切な数字じゃないですか？」
「システム無応答でこれだけの生産性影響が出ていると考えられます、これを解消する一番効果のありそうな提案をします、だからこれだけ費用を出してください、と相談したらどうでしょう」
CPU増強の費用は、インフラコスト観点で計算していい。でもCPU増強の効果は、インフラ影響ではなくビジネス影響で量るのだ。
90年代の終わり、まだシステムはすべてオンプレミスだったある日、ERPシステムのトラブルで、SIerの新入社員だった僕は現地対応に詰めていた。現地システムから情報を取って社内のエキスパートに電話で伝え、社内エキスパートの説明をお客様に伝え、社内エキスパートの指示で現地システムの復旧操作をする、「現地の目・口・手」の役目。徹夜を経て翌昼が近づいてもシステムは復旧しない、そんなタイミングでお客様から声をかけられた。
「窓から見えるそこの建屋、あれ工場なんですけどね。このシステムから今日の生産指示書が出るのを待ってるんですよね」
スタッフは出勤していて給与は発生しているし、資材も集められていて中には継時劣化する生モノとか揮発性の薬品とかあるかも知れない。システムの向こうには業務があり、事業があり、ビジネスがあって、損益影響がある。そのことがこの時、本当に骨身に沁みた。だから今回の相談でも、システムの不安定化やその安定化にビジネスインパクトがどれだけあるか、それを起点に話し合った方がいいのではと思ったのだ。
Dev・Ops・Bizで決める監視項目
先日開催されたばかりのAWS Innovate Modern Appication Editionのオープニングセッションでは、僕が今回なにをあるべき形と考えていたのか、このサービスオーナーと運用担当には何が必要だったのかを明確に言語化し考えなおすことができた。
例えばあるウェブサイトがあるとします。そのウェブサイトは特に障害を起こしていない。なんのエラーも吐いていない。しかしユーザーがアクセスしウェブサイトが画面に表示されるまで、2秒かかっているとします。
これは今回、問合せを受けた社内システムで起こっていたことと近い。社内システムの方は、おそらく利用期間に伴うデータ増加によって、無応答時間が発生するようになった。
昔の考え方であれば、インフラ側は障害ではない、アプリケーション側は何か問題を感じているという状態ですが…
導入を決め（Biz）導入フェーズを実施（Dev）したサービスオーナー側は、時間を空けてアクセスしなおせば利用可能で「障害ではない（障害とみなすほどのことはない）」と感じている。しかし障害問合せをたびたび受けている運用（Ops）側は「何か問題を感じている」。Ops側は、これをCPUリソース不足の可能性が高いとにらんでいるが、リソース増強は追加開発に当たり、DevまたはBizの予算を割り当てられないと行えない。
アマゾンが言うDevOpsではこれを傷害とみなす必要があります。なぜならそのシステムは本来ユーザーに2秒たってなにかを表示させることを目的として存在していないからです。
Ops側では「これを傷害とみなす必要があります」と言いたいのだけど、「なぜなら」の後をどう続ければいいか悩んでいた。僕がしたのは、だから「そのシステムは本来利用者を待たせて時間を浪費させることを目的として存在していない、逆に利用者の時間当たりの生産性向上を目的として存在しているはずだ」という整理を手伝うということだった。
DevOpsチームをつくる際まず行うべきなのはMetricsの合意です。ここには技術関係者だけではなく、必ずビジネス関係者を介在させる必要があります。そのビジネス要件を技術要件に変換した後、それを担保するためにどのようなデータを取得するべきか。なにか問題が起きた際にはどういた改善計画をあらかじめ備えておくべきか。（略）単純なところでいえば、ピークを迎えてシステムが遅くなっていく際にはオートスケーリング、コンピュートリソースを増やすなど、そういった改善計画をどのように準備していくかというMetrics、つまり共通言語を作っていく必要があります。
でも最初に思ったのは「CPU使用率が高い時に何をするか」で揉め、「CPU使用率が高いとなぜ問題か」が誰も説明できないなら、なぜCPU使用率を監視することにしたんだろうということだった。だって、監視をすることにもコストはかかる。でも監視すること自体が目的じゃないのは明らかだ。ほとんどの場合、監視目的は、ビジネス要件の実現の「維持」か「向上」だ。じゃあ、「維持できてない」「向上してない」時のアクションプランまであっていいんじゃないかな。
もし今回のことで、このシステム関係者が恒久対策を考える気があれば、ぜひここを見直してもらえたらいいと思う。アラート発生時のアクションと、そのビジネス影響。それをすれば、アラートや障害報告が上がってるのに増強や改修の理由付けに悩む、なんてことはなくなると思う。
コンサバSIerとDevBizOps
僕はこの社内システムがどんなものかまったく知らないけど、AWSとはいえEC2だしオートスケールもしてないし、多分レガシーアプリケーションの作り方だろう。僕たち自身も、事業のボリュームゾーンで判断すれば、おそらくコンサバ寄りのSIerだ（この「社内システム」がSIか自社内か非実在かは想像に任せるけど）。モダンアプリケーションとかCDとかとは、まだだいぶ距離が遠い感じがある。
それでも「まず行うべきなのはMetricsの合意」「ビジネス要件を技術要件に変換した後、それを担保するためにどのようなデータを取得するべきか。なにか問題が起きた際にはどういた改善計画をあらかじめ備えておくべきか」という話は必要だった。新しいモダンなソフトウェア開発論は、新しいとは言ってもソフトウェア業界あるあるを何とかしようと編み出した考え方や手法なので、レガシーアプリケーションでもコンサバSIerでも接点がないはずはない。実際、DevBizOpsの考え方が必要だったのだから。
ちょっと前にCCoEってなんだろうと考えたけど、こういう「クラウドっぽいやり方・考え方」を少しずつコンサバSIer内で実践し、少しずつ組織と風土を変えていくようなことも、その役割なんだろう。問合せ対応なんて、困りごとにクラウドっぽく解決を提供する、「クラウドっぽい」を体験してもらう格好の機会だ。そうやって少しずつ、コンサバSIerだけどDevBizOpsが普通、に変えていく。Strangler Figのようにゆっくりと、巨木を作り替えていく。