はじめに
2019年に監視論 を発表し多くの「いいね」を頂きありがとうございました。
システム監視を取り巻く環境は、DevOpsやサーバーレス、Observabilityなど進化を続けている。
2020年はこれらの動向を踏まえて、監視エンジニアやMSP事業者に求められる役割について考察する。
SREの役割
SRE（Site Reliability Engineering）の役割は性能、可用性、セキュリティーを担保し、サイト（サービス）の信頼性を確保することである。
このためにインフラモニタリングやAPM（Application Performance Management）を行いリソースやアプリケーション実装上の問題点を見つけ出し対応策を策定することが重要となる、
監視の役割は開発ではない
SREが登場した当時DevOpsの文脈が強くOpsやSREも開発を行うという総員コーダーのような雰囲気が強くなった。
しかし、DevとOpsはそれぞれ適性も異なり、どちらかがどちらかの上位互換という分けでもない。
OpsやSREの本領はパフォーマンスの分析でありそこで求められる能力は統計やログ解析、アプリケーション解析である。
一部のスーパーエンジニアや小規模、少数精鋭のスタートアップであれば開発者兼SRE
一人DevOpsなどのアプローチが可能であるが
大規模SaaSなどであればSREとソフトウェアデペロッパーは別のチームとなる。
そこでSREやOpsに求められる役割はモニタリングに基づいたソフトウェア改修ではなく、
改修するための根拠となるデータを示し、設計フェイズに対してフィードバックを行う事である。
設計と監視 Opsサンドイッチ
ごく小規模な体制でなければ、OpsやSREとDevは別の組織となる。
そこでOpsが行うべきは自分たち自身がDevになることではなく、Devが適切な改修を行えるようにその前段階の設計に対して実装要件としてフィードバックを行う事である。
インフラモニタリングはマルチスレッドプログラミングの偏りやメモリリークを検知可能であり
ミドルウェアモニタリングはDBコネクションプーリング実装の不備を検知可能であり
APMでは非効率な再帰呼び出し実装や外部SaaSとのデータ連係実装の効率を判別することが可能である。
これらはあくまでも測定値であり値から意味を読み取り設計へとフィードバックすることがこれからのMSP事業者やSREに求められる能力である。
まとめ
MSP事業者やSREは開発能力ではなく読影能力および設計能力を高める事が重要である。
この能力および設計にフィードバックを行うというモデルであればMSP事業者が社外SREとして機能することが可能となる。
これらのMSPやSREが真に力を発揮するためには分析に基づくフィードバックを適切にソフトウェアの実装に反映する開発体制が必要となる。
旧来からの長期間ウォーターフォール開発ではフィードバックを適切に反映することは困難である。
分析対象となるデータ期間を考慮すればモニタリングからのフィードバックを反映しその効果を確認するまでの期間は1週間以内長くとも1ヶ月以内が理想的である。
そのためにはMSPのレポートサイクルも同様に短縮する必要があり、さらに開発モデルも
同様にショートウォーターフォールあるいはアジャイルモデルが必要となる。
モニタリングデータの読影には経験や専門知識が必要であり、これを全ての開発組織が保有するよりは、MSP事業者が専門家として提供する方が日本においては現実的であると考えられる。
その上でMSPを社外SREとして有効に活用するためには開発組織の進化も必要である。