可制御性と可観測性
ちゃんほ氏は、「制御工学に由来し、運用設計の場にも応用できそうな概念」として、「可制御性」と「可観測性」という概念を示していました。なお、当人は「学生時代に制御工学を専攻していた」というバックボーンのある人物です。
- 可制御性
- 入力が出力に影響を与えられること
- 可観測性
- 入力の内容から出力を推測できること
運用現場のAs-Is
運用方式設計のAs-Is
ちゃんほ氏は、「運用方式設計のAs-Is」として、以下の事柄を挙げていました。
- 漠然としたツール導入
- 漠然とした監視
- 漠然としたオペレーション
「何をするツールなのかわからないけどとりあえず導入する」「何を示しているかわからない値だけどとにかく採取する」「何の意味があるオペレーションかわからないけどとりあえず継続する」…担当者が不健康になる運用現場のあるあるですよね。「何を狙いとしてそのツールを導入するか」「システムのパフォーマンスと強い相関のある指標は何か」「その手順には何の意味があるのか」…ミレニアル世代の人材に対する運用計画と同様、運用方式設計にも「適切な動機付けと、目的の明確化」というのは大事なのです。
システムリソース運用に対するクライアントの無茶振りと、その抗弁策
PCに関するさまざまなリソースは、往々にして「使用率が100%に近くなると急激にパフォーマンスが下がる」ものです。CPUの使用率しかり、記憶領域の空き容量1しかりです。しかし、そうした実態に疎いクライアントは、えてして「CPUを100%使い切れ！」等の要求をしてしまうものだそうなのです。運用担当者としては悲しい話ですよね。
運用現場がこうしたクライアントの無茶振りに抗う戦略は、やはり「図表によりエビデンスを示す」というのが有力だそうです。ちゃんほ氏は、「横軸にCPU使用率、縦軸にレスポンス時間を取り、CPU使用率60%前後から急激にレスポンス時間が長くなるグラフ」を例として示していました。
クラウド時代の運用設計
- 「運用」というのは、「サービス提供の維持」と考えるべき
- スケールアウトが容易になり、可制御性の確保も容易になった
クラウドにおいては、「クラウドベンダーが提供するAPIにより提供される範囲を超えることはできない」というのが大前提です。そのため、方式設計で取りうるアプローチの選択肢はオンプレミスより狭まります。さらに、システムパフォーマンスを示す指標を採取できる範囲にも限界があります。「システム監視」というやり方ではどこかで破綻してしまう、そういうものと考えたほうがいいでしょう。
