はじめに
ここでは、開発から引き渡されたコードやシステムを、運用でスムーズにSREの営みにのる事が、想像される一番よい状態ととらえたときに、実際におこりそうな足りない物事（課題・問題）について随筆します。
私個人の想像なので（フィクション）、これをお読みになった皆様から、想像の正誤について、ご意見、コメントをいただけるとうれしいです。
システム構築から運用へ
すっごく雑に書きますが、SREと言えば、サービス / サイトが安定して稼働する事に関するエンジニアリングなので、システム構築とは違うものだと思っています。
システム構築を外部へ発注した場合、プロジェクトで取り決めされた形でシステムが納められると思いますが、そこにSREで必要な要素が加味されているのかというと、プロジェクトによってマチマチなのが今ではないかと思います。
例えば、「自動化された運用機能」ではなく、「（自動化されていてほしい）運用操作手順書」が納められるのではないでしょうか。
もしそうだとすると、受け取ったシステムをSREの営みにのせるために、機能を追加するというのが、運用の最初のタスクとなるのではないかと考えます。
つまり、新しいシステムを受け取ると、まずは新たなToilの種がまかれて、Toil排除を目的とした自動化の実装というタスクが生まれるんだろうなと思います。
何となくですが、Toil は日常の運用業務でシステムと対峙してみないと、何がToilなのか整理できない気がします。ですので、システムの仕様として運用機能の実装を事前に依頼するのも難しく、結果、システムを受け取ってから自動化を実装するといのは当然の事になるのでしょうか。
打倒Toil?
そうだとすると、SREチームには、このToil 排除に取り組めるエンジニアの必要性がでてきますが、果たしてそのエンジニアにはどんな知識が必要となるのでしょうか。
答えは、「システムを構成する要素を全般的に理解できるエンジニア」となると思います。つまりシステムの構成要素に依存して、必要な知識範囲はことなると考えます。ですので、具体的な知識の定義は出来ない。。。
この実に様々な知識が必要なエンジニアに参画してもらうというのがSREへの取り組みの大きな課題となっていると思います。
例えば、GAFAのような企業なら、サービスを構成する要素の多くを一から組んでいると思いますし、サービス提供そのものがビジネスの根幹に位置づけられていると思うので、そこがSREに取り組むならそういった幅広な知識をもつエンジニアを集めることがそのまま企業の競争戦略にリンクするすると思います。
一方で、多くのDXが途上の一般的な企業のITにおいてはなかなか難しいのも現実で、エンジニアを集めたり、育てるといったところで苦戦していて、DXの取り組みが鈍化していたり、SREに踏み込み切れないといった問題を招いているのかも？と想像します。
（突然、DXという言葉を出してすみません、そもそもの持論を書いていないので、違和感があるかもしれませんが、ここはご容赦ください。別の機会に書きたいと思います。）
それでは、諦めますか？
どのような前提で、SREへの取り組みを実践しているにしろ、目標がある以上は、諦められないと思います。そこで、もし、そこに有効な手段があるとしたら？ということで、いくつか施策を考えてみます。
-
それでも自動化込みでシステム構築を委託する
いいと思います。しかしながら、前述のとおり、予め、自動化ありきで構築してもらう為には、自動化された機能が、予定したものとなるように、システムのアーキテクチャや、採用される非機能の実現方法等色々な前提を置く必要があると考えます。
とすると、未経験なテクノロジーの採用を阻害したり、非機能要件とコストのバランスをとれるのかが制約になる懸念があります。 -
内製する範囲をより広げて、運用の作り込みは運用フェーズで並行して行う / または、受け取った手順書を自動化スクリプトに置き換えていく
オーソドックスな判断の一つで、いいと思います。ただ、これは、ほおっておくと、そのままハイスペックなエンジニアをチームに招くことと同義になる事が予想されます。対策として、1. の項目と同様に、予めシステムアーキテクチャや、非機能要件をパターン化して、必要な知識の範囲を制限していくアプローチが現実路線かなと思います。
いわゆる、過去実績のあるやり方や、現行を踏襲とかそういう要求がもりこまれる事に近いと思います。
よって、制約や制限については、1.と同様になるかと思います。加えて、運用の立ち上がるまでに、最低限の道具が整う必要があるかもしれません。ここはサービスのローンチにたいしてリスク要素となり得ます。 -
運用の作り込みが容易なテクノロジーを積極的に採用する
これが、今現在、比較的多く取り組まれている事ではないかと思いますし、私の一推しアプローチです。ただ、アプローチの実際は、実は、１や２と変わらないもので、その前提のテクノロジーをどう選択するべきかという点で発展的なアイディアです。
端的に、IaaS / PaaS / SaaS やそれに類するテクノロジーを積極的に採用します。
クラウドサービスは、その素性から、ベアメタルサーバ上や仮想化環境上に、ソフトウェアを展開し、並べてシステムを構築するよりも、より高いレイヤーで抽象化されています。（乱暴ですが）抽象化されているということは、その裏側は、少なくともXaaS利用者からみれば、インターフェースの先は自動化されているのと同義ととらえます。
うれしいこと（？）に、選択できるテクノロジーは、プロバイダーの提供形態やメニューに限定されるので、ありとあらゆる選択肢よりは、必要な知識の面でより範囲が狭くなる期待が持てます。一方で、トレンドとして魅力的な機能や仕組みは、サービスとして、プロバイダーのAPIで標準化された上で提供されるので、比較的新しいテクノロジーの採用の敷居も低いかもしれません。
ただし、クラウドプロバイダー前提でシステムを構築することが望ましくないケースには注意が必要です。オンプレミスな環境でシステムを構築する場合には、前述の１や２のアイディアと同じになってしまいます。この点にとれる対策としては、環境を選ばず、よりニュートラルにフラットに同様の恩恵を受けられる仕組み（例えば、オンプレ環境への（より抽象度が高いという意味で）OpenStackの導入や、アプリケーションの実行環境には多くのクラウドプロバイダーでもマネージドサービスが提供されている、kubernetesの導入）を組み合わせて取り組むことで解決できる可能性があります。 -
SREとは、Toil 排除だけじゃない。なので、別の取り込める要素だけ取り込む
これはどうでしょうか。確かに、うれしいエッセンスは沢山ありそうですが、運用体制は、ある想定されるタスクのもと組織されていると思うので、そんな中、高度化していく余力はないのが現実だと思います。
あえて極端に書きますが、もし、そこに投資する判断ができる企業があったとしてSREを新たなやり方として取り組むなら、運用体制を数倍に拡大するようなことになると思います。
また、手数が増えるので、エンジニアの負担は減らせて、エンジニア一人当たりの知識の範囲を分散できるかもしれませんが、属人化は回避しにくくなりそうです。また、もし、運用手順を人手で行うのなら、安定性が向上するのか、スピードが改善するのかといった効果を私は想像できません。
まとめ
ここまで、従来IT構築のアプローチを前提として、SREに取り組むなら？という観点で書いてみました。結局、どのように自動化に取り組むか？というミクロな話になってしまいましたが、書いてみた結果、SREを加速させるいくつかのポイントがありそうです。
- ハイスペックなエンジニアは容易には調達できない
- より知識の範囲を限定していくために、抽象化されたテクノロジーの採用は期待できそう
- SREを実現するために、恒久的に手数を増やすのはナンセンス（？）
となるかなと思います。
拙い文章でかつ妄想要素を多分に含んだ内容でしたが、最後までお読みいただきありがとうございます。