DevOpsの慣性とIT運用の調整に関するMircoHering

Mirco Heringは、APACDevOpsおよびAgilewithAccentureのプリンシパルディレクターです。彼は、効率的なIT配信を求めて、オーストラリアおよび海外の主要な公的および民間部門の企業をサポートしています。 IT配信に関するMircoブログ NotAFactoryAnymore.com の作者です “現代のエンタープライズ向けのDevOps：レガシーIT組織を変革するための勝利の実践。」TwitterでMircoをフォローする @MircoHering.

OpsRamp: 従来の企業がIT組織全体にDevOpsプラクティスを組み込むのに時間がかかるのはなぜですか？

MH: ほとんどの組織は、どういうわけかDevOpsを使用していると言っています。しかし、DevOpsには非常に多くの定義があるため、頭を動かすのは困難です。それが正しく行われているかどうか確信が持てないため、成熟度評価を考慮すると、これは問題です。 Jenkinsパイプラインがあるので、DevOpsがあると言われるかもしれません。彼らは目標を低く設定し、それから彼らは政治的に成功を宣言する必要があります。しかし、それはDevOpsの基本的な概念を誤解させます。それは継続的な改善についてです。

あなたがその考え方の変化を理解していない場合、あなたは決して利益を得ることができません。一般的な神話は、DevOpsは組織構造の演習であるというものです。開発者と運用担当者をコーヒーで一緒にすることができれば、多くの問題を解決できます。しかし、それはそれほど単純ではありません。ベンダーはすべて開発ツールとコード管理ツールの名前をDevOpsに変更しているため、ツールに重点を置くことでこれもさらに困難になっています。ただし、残念ながらDevOpsを購入することはできません。

OpsRamp: 本当のDevOpsの成熟に向けて進むために、あなたは本当に何を突き止めなければなりませんか？

MH: 答えは1つではありません。ほとんどの問題は多面的です。私たちは現在の状況を理解する必要があります。問題は何ですか、それが問題であることをどのように知ることができ、それからどのようにそれを改善することができますか？したがって、実験を実行して状況が変化するかどうかを確認してから、プロセスを繰り返します。なぜウェブサイトがグリッチを続けるのか、なぜ私たちが十分な速さでリリースできないのかを理解したいと思うかもしれません。

ただし、何が起こっているかを確認するには、まず、適切なデータを用意する必要があります。そうすると、バグの4分の1だけがコードの問題によるものであり、他のバグはデータ統合の問題と構成の問題に関連していることがわかります。 DevOpsを介して問題解決に取り組むには厳密さが必要です。

OpsRamp: DevOpsは、役割をめぐる混乱や対立のために、より多くの対立と慣性を生み出しましたか？

MH: 以前は狭い役割でしたが、今ではより広くなっています。開発者はいくつかのテストを行う必要があり、テスターはテスト自動化スクリプトを作成する必要があります。以前は常に仕事のヒーローであったときに、間違いを犯していると見なされたくないため、新しいスキルを習得することに不快感を覚える人もいます。そして、本当に苦労しているのは、大きな青写真や図を作成していた従来のITアーキテクトです。現在、環境はもはやそれほど予測可能ではありません。私たちは一日中マイクロサービスを展開しているため、環境を事前に規定することはできません。

計画と設計は流動的で、非常に速く変化します。そのため、ガイドラインと原則を設定するアーキテクトが必要ですが、それらを開発チームに統合して、トップダウンの指示ではなく双方向の会話にする必要があります。苦労しているもう1つのグループは、プロジェクトマネージャーです。 DevOpsとアジャイルではそれらは必要ないという考えがありました。ただし、管理が多すぎるから少なすぎるように修正しすぎたと思います。プロジェクトマネージャーがさまざまな関係者や利害関係者の管理を支援することには利点があります。

OpsRamp: 世界的大流行をきっかけに、企業はアジャイルおよびDevOps配信機能への移行を加速し、新しいアプローチがありますか？

MH: はい、私はこれらの分野が加速すると思います。システムが迅速に対応する必要性が高まっています。たとえば、失業保険の請求で政府のシステムに大きな打撃を与える人が増えています。そして、政府がより多くのDevOpsを採用すれば、他のすべての人がそれに続くでしょう。在宅勤務もあり、働き方も変わりました。つまり、作業の管理を支援するために、より多くのエンドポイントのセキュリティと自動化が必要になるということです。

ITで物事を成し遂げるために、物理的に調整する機会はありません。

「パンデミックの前にすでに高度な自動化とDevOpsオーケストレーションを行っていたクライアントがいますが、現在、分散した従業員でリリースを行う際に問題は発生していません。」

OpsRamp: 開発、QA、運用、セキュリティなどのさまざまな機能にわたってアジャイル/ DevOpsチームを構築するためのいくつかの勝利の実践は何ですか？

MH: 私は以前エンジニアだったので、人々に学習に興味を持ってもらう必要があることを理解しています。体験トレーニングや道場などの戦術が役立つ場合があります。前者では、動作をシミュレートして、変化がどのように感じられるかを確認できます。ゲームのようなものです。新しいプロセスを試すときに、状況がどのように変化しているかを人々に示すことができます。道場チームを取り、実践的な練習を通じてツールの使用法を学ぶことができる構造化された環境にチームを配置することによって作業します。サンプルアプリケーションでミッキーマウスの演習を行うのではなく、ビジネスの実際の作業を行っています。それはしばしば学習体験に大きな違いをもたらします。

そして人々は彼らが行くにつれてコーチから専門家の助けを得ます。このように長時間操作できれば、通常の作業環境に戻ったときに変化が起こります。スプリント（2週間）未満のものは、実際にはうまく機能しません。リーダーは、道場で学習している間は、チームから同じスループットが得られないことを理解することが重要です。スピードを上げるにはスローダウンする必要があります。ほとんどの組織では、変革の旅に出てから実際の変化が見られるまでに12〜18か月かかります。