DevOps now-10年前のバージョン管理のように、まもなく全員がそこにいます

「DevOps」のコンセプトについて無限に議論することができます-欠員、ポジション、指示、KPIなどがあります...しかし、私はビジネス、管理者、開発者の間でこのコンセプトに対するまったく異なる認識を常に見ています。 前者はDevOpsを方法論として、後者はルーチンを自動化するためのツールセットとして、そして3番目は展開のためのツールセットとして認識しています。 ある意味では、誰もが正しい。



上記の各ポジションからこれらのプラクティスを検討することにし、これについて長い間料理をしてきた人々に尋ねました。 どうしたの？ カットの下を見てください。









Baruch jbaruch Sadogurskyは、ロシア語を話す最も著名なDevOpsの第一人者です。 最近では、基本的に3つのことを行っています。開発者、ユーザー、顧客と付き合い、彼らのためにコードを書き、ブログや会議で印象について話します。 デブリーフィングポッドキャストの定期的なチャンクであるJFrogの開発者支持者。 バレーで最もクールなDevOpsカンファレンスであるswampUPの主な主催者の1人。



Alexander TitovはExpress 42の管理パートナーであり、テクノロジー企業でDevOpsを成長させています。 かつて、彼はロシアで最初のクラウドホスティングであるSkalaxiのテクニカルディレクターでした。 DevOpsモスクワコミュニティの主催者、DevOpsDaysモスクワ会議。



-DevOpsは、同じ製品の開発と提供に関与するチーム間の相互作用の問題を解決します。 さまざまな専門分野の人々の間のそのような相互作用の原則は何ですか？ 責任の明確な境界を定義する方法は？



アレクサンダー・ティトフ：質問は単純でも複雑でもあります。 私はこれとその両方に答えようとします。



「責任」はかなり単純な言葉です。 それはあなたがしているビジネスを理解するために何かを説明する機会、責任を負うことを意味します。 これは、賞品を失ったり、KPIを満たさなかったりする恐れと同等ではありません。



だから、何かを知らずに自分を決定し、認めるのに役立つ知識を含む特定の分野の知識を持っている人は、答えになります。これは彼の境界です。 同時に、人は責任を持って、そして意識的に知識の境界を越えて知識を受け取ることができます。



これは責任の問題に対する単純な答えです。個人、チーム、企業が知識の限界を知るのに十分です。 そうすれば、私たちが不安定な氷の上を歩いている場所と、私たちが堅固な地面の上にいる場所を常に理解できます。 大まかに言えば、個人またはチームが環境内でKubernetesがどのように機能するかを知っていれば、Kubernetesに対して完全に責任を負うことができます。 または、たとえば、人がアプリケーションを作成し、それがどのように機能するかを知っている場合、彼はその責任を負います。



難しい答えは、会社の知識を判断することは非常に難しいということです。人々は嘘をつき、恐れており、実際に知っていることとそうでないことを認めません。 人々は自分が何かを理解していないことに気付かないことがよくあります。これは無意識の無能とも呼ばれます。 ここで役立つのは、チーム内で信頼と継続的な対話の文化を培うことだけです。 誰もが別の間違いを指摘できます。2番目の間違いはこの指示を無視できませんが、彼はそれを反省し、他のチームメンバーと話し合い、答える必要があります。 そして、この文化は、DevOpsを実践しているチームの相互作用の基盤です。



-企業が開発に対する標準的なアプローチを長く守ってきた場合、DevOps方法論のために人々を「再構築」するのはどれほど難しいでしょうか？ これでどのような問題が発生しますか？



アレクサンダーティトフ：人々を再建するのは難しい。 一般的にファシズムの人間の再構築のアイデア;これらの人はまた、スーパーマンを「構築」することが可能であると考えました。 多くの非常に複雑なタスクを教育し、解決する必要があります。

• 考えることは本当に問題の解決に役立つことを人々に示す必要があります。
• 人々は、独白ではなく対話を行う方法を学ぶ必要があります（通常の会議を見てください-しっかりした独白があります）。
• 人々はオープンで誠実でなければなりません。
• 多様な経験が素晴らしいことを人々に示す必要があり、絵画の知識はソフトウェア開発に役立ちます。

大きな問題は、基本原則の理解不足です。多くの人がそうであるように、人々を再編成するのではなく、これらの人々自身が私が挙げたスキルを習得できる環境を作ります。 マネージャーは、自分が変わったときにのみこのような環境を作成できますが、これがここでの最大の問題です。



自己変革のための私のレシピはコミュニティの仕事です。 信頼モードで環境を作成する方法を簡単に確認できるのは、コミュニティです。 締め切りとボーナスが彼に圧力をかけているとき、リーダーが環境について考えることは非常に難しいです。



Baruch Sadogursky：最大の問題は、技術者が文化の変化を正しく評価することが難しいことです。 技術者たちは、今はジェンキンスを採用すると考え、Dockerを磨き、DevOpsを手に入れると考えています。 しかし、DevOpsはツールだけでなく、アプローチを変えることでもあります。 これ以上システム管理者や開発者がいないという事実。 コードを書く人がいます-そして彼らはコードが生産に入ることを保証する責任があります。



誰もが、適切なツールをセットアップして、コードを作成する人がすべてを実稼働にデプロイし、その後DevOpsが実装されたことを発表したいと考えています。 そして、次のデブリーフィングで、何かが生産に入っていないことが判明したとき、開発者は否定しました。「言われたとおり、ボタンをすべてクリックしました。今では問題ではありません。 それを設定した人が行って修正します。」 そして、パイプラインを設定しても、DevOpsを取得することにはならないことがわかりました。 コードを書く人が「これらは私たちの問題ではない」というフレーズが基本的に使用できないことを理解するまで、DevOpsについて話すことはできません。



これで、技術者によって作成された技術トピックに関する素晴らしい会議が開かれます。 Jenkins、Ansible、Docker、Puppet、その他のさまざまな素晴らしいツールがたくさんあります。 適切な構成でDevOpsを取得する方法に関する多くのレポートがあります。 これは私たちが理解し、話したいことです。 私たちが正しくできること。 文化を変える方法についての報告がありますが、これを行うことは非常に困難です。 一般に、これは技術者の問題ではなく、心理学者、社会学者、または行動の専門家の問題です。



-DevOps-methodologyは、あらゆる種類の自動化を意味します。 これは、企業にとって製品の発売とサポートが安くなるということですか？ DevOpsを実行することをお勧めする境界を決定する方法？



Baruch Sadogursky： DevOpsは、製品の生産をより早く開始し、リリースをより頻繁に行い、開発をより速くするために作成されたばかりです。 DevOpsを実装している、または実装を計画している企業の調査結果を見ると、それらの80％が、主要な最も重要なドライバーとしてクイックリリースを特定しています。



実装の境界という点では、実際、DevOpsはあらゆる規模のチームに役立ちます。 この方法論のチームの1つまたは別の規模への適用性について質問することは、10年前にバージョン管理を使用するのが理にかなっているサイズを尋ねることと同じです。 今日では、この質問はもう行っていません。技術的なコラボレーションのためのツールがすでに2つも必要であることは明らかだからです。 DevOpsもツールボックスです。 そして、今日私たちがコードを書いてそれをバージョン管理に送ることが当たり前だと思ったら、10年後に同じ方法でコードを書き、本番に送ります。 これらは同じレベルのものです。 まだこの点に達していない。



おそらく、プロジェクトに3人の人がいる場合、結果は目立たなくなります。 また、100人のチームが使用するすべてのツールが必要なわけではありません。 しかし、DevOpsパラダイム自体（コードを記述するだけでなく、本番環境で動作することを確認し、必要なものがすべて配信され、必要に応じて展開され、品質が適切であることを確認する必要があります） 1人、3人、そして100人のチームです。 ツールボックスのみが変更されています。



-DevOpsがプロジェクトを支援しなかった（または干渉さえした）場合の例を挙げることができますか？



Baruch Sadogursky：この観点からすると、DevOpsはアジャイルに似ています。 スクラムを実装した多くのチームがありますが、何も機能しませんでした。 答えは簡単です。文化とツールを区別する必要があります。 ツールは適切である場合とそうでない場合があり、適切に実装されている場合と不十分に実装されている場合があります。 それらが不十分に実装されている場合、それはおそらく良いもので終わることはありません。 しかし、より大きなコラボレーションの文化、コンセプト自体は、別の障壁を取り除くことを提案しており、悪くはありません。



過去20〜25年にわたる業界のすべての文化的変化は、より大きなコラボレーションにつながります。 最初は継続的な統合がありました。 それはより多くのコラボレーションについてです-開発者がリリースの前に年に一度それをするのではなく、早い段階で統合について考えることを望みます。 これで、各コミット後（または毎晩）統合が行われます。 アジャイルも。 コラボレーションが向上し、人々がより多くのコミュニケーションを行えるように、チームを分割します。 昼間のmitapがあり、情報交換が改善されました。 DevOpsが登場しました。 彼はまったく同じことです-私たちは別の障壁を取り除いています。 このアプローチの有効性は、長年の経験によってすでに正当化されています-障壁を排除することで、リリースの高速化、品質の向上、その他すべての利点が保証されます。 唯一の問題は、これがどのように実装されるかです。



-最近、効果的なDevOpsチームを編成するのはどれほど難しいですか？ エンジニアにはどのような能力が必要ですか？ また、「別個のDevOpsエンジニア」が必要ですか？



Baruch Sadogursky：私たちは文化の問題に戻っています。 私たちは技術者であり、さまざまなツールを使用する方法を知っています。 しかし、チームとして正確に機能するチームを編成することは最も困難です。 技術的な観点から、開発者とIT（システム管理者）の2人が一緒に仕事をしたい場合、それ以上の作業は必要ありません。 彼ら自身が必要なツールを作成して構成し、お互いから学ぶことができます。 しかし、これが文化的な観点から意味することを理解している人々を見つけることは最大の挑戦です。



アレクサンダーティトフ：私のレポートでこれについてお話します。 しかし、要するに、「DevOpsエンジニア」は、当然、誤解からのアプローチであり、避けられない現実から逃れるための試みです。 同社は、技術製品を作成する方法を選択し、技術について読み、DevOpsエンジニアまたはチームを雇ってDevOpsの方向性を閉じ、アジャイルコーチチームを雇ってアジャイルの方向性を閉じます。 そして最終的にはどうなるかがわかります。



実際、DevOpsはいくつかのコンピテンシーをカウントできるようになりました。

• インフラストラクチャエンジニア（低レベルプラットフォームを提供するエンジニア-リソース、ネットワーク、建築機械）;
• 一般的なサービスエンジニア（モニタリング、ロギング、サービスとしてのデータベースを作成するエンジニア）;
• 製品開発エンジニア（直接アプリケーションおよびアプリケーションの構成の開発者）;
• CIエンジニア;
• リリースマネージャーまたはリリースプロデューサー（バージョンのリリースを作成し、製品全体をコンポーネントのセットとして管理するマネージャーまたはエンジニア。現在では、テクニカルディレクターがこの役割を果たすことがよくあります）。

そして、これは能力の配分のほんの始まりに過ぎません。



-DevOpsの規範によると、製品の開発とサポートに必要なツールについて教えてください。 現代のツールはどの方向に進化しますか？



Alexander Titov：ツーリングは、製品を作成し、これらの製品の仮説をテストするための便利な技術環境の構築に焦点を当てています。 Amazon、GCP、Azureなどの既製のエコシステムがすでにあります。 カスタマイズされたエコシステムの基礎となるツールがあります-Kubernetes、Ansible、Jenkinsはその構成要素になることができます。 Dockerは特別な役割を果たしました。アプリケーションの構成と構成に関する知識をパッケージ化し、標準化するためのツールになることができました。



ツールは安定性を高め、サービスとエンジニア向けサービスの作成に向けて進化します。 例としては、機械学習を使用してアプリケーションを統合し、問題を特定したり、テストしたりする場合があります。



-ツールキットに未解決の問題はありますか？



Barukh Sadogursky：多くのツールがあります。 時間が経つにつれて、それらはますます多くなり、それら自体が良くなっています。 今では、探すべき特別なものはもうないように思えます。 DevOpsは初期の多数決段階に達しました-誰もが多かれ少なかれ理解しています。



もちろん、個々のツールは引き続き開発および改善できますが、ダークスポットはもうありません（「これをどのように行うか、誰も知りません」）。 独自の特定の問題が存在する他の市場があります。 そして、ツールプロバイダーに関しては、私たちにとって興味深い「ダークスポット」がまだあります。



-すべてのチームに必要な最小限のツールに名前を付けることは可能ですか？



Baruch Sadogursky： DevOpsは最小限の製品に実装できます。 GitHubの問題など、問題追跡ツールが必要です。 当然、GitHub自体はコードとバージョン管理に必要です。 継続的な統合サーバーが必要です-いくつかの基本的なJenkinsまたはクラウドソリューションでさえ-それらの多くがあり、すべてを実行するプラットフォームがあります。 始めるにはこれで十分です。



多くのチームが相互作用する複雑なシステムには、最も単純なツールで十分ですか？ もちろん違います。 しかし、この基本セットは、完全に自動化された継続的インテグレーションまたは継続的デリバリを構成して、DevOpsスタック全体を取得するには十分です。 それはDevOpsを意味しますか？ いや すでに述べたように、問題は文化にあります。



-技術的なコンポーネントについて少し。 QAはDevOpsのコンポーネントの1つと見なされます。 QAエンジニアの生活はどの程度複雑/単純化されていますか？



アレクサンダーティトフ： QAエンジニアの人生は複雑にならず、単純化も変更もされません。彼は、アプリケーションの信頼性と他のアプリケーションとの統合の可能性を判断するコードの記述を開始します-これは、スクリプトに従ってサイトをクリックするのと比べると、わずかに異なるタスクです。 一般に、私は、プログラミングコースを開始するためにサインアップするためのプログラミング方法を知らないすべてのQAエンジニアにアドバイスします。



-DevOps方法論の実装後のビ​​ジネスにとってのメリットは何ですか？



Barukh Sadogursky：私が言ったように、ビジネスは2つのことを望んでいます。成功と競争力はそれに依存するため、より速くリリースし、より高い品質でリリースします。 80％の企業が、これら2つの機能のためにDevOpsを必要としていると答えています。



-DevOpsにより、ビジネスは外部の変更により迅速に対応できますか？ 何が起こるのですか？ それとも妄想ですか？



Alexander Titov：このためにDevOpsが作成されています（まだ作成されていないため、まだ始まったばかりです）-これは、市場をすばやく調査し、ビジネス仮説をテストできるソフトウェアを作成するためのアプローチです。 これは、すべてのアプローチとツールがこのアイデアに基づいて作成されているためです（他のアイデアで作成されたアプローチとツールはDevOpsではありません）。

---

2週間後にサンクトペテルブルクで開催されるDevOopsカンファレンスでは、バルークとアレクサンダーが「DevOpsを同僚、上司、その他の無関心な人に販売する方法」という円卓会議を開催します。



Alexander Titovは、レポート「システム管理者から個人へ」で 、システムとしてのDevOpsについて説明します。 それがビジネスにどのように役立つか、エンジニア側の能力がDevOpsにどのように現れるべきか、ソフトウェア生産のDevOps-methodによって解決できるビジネスタスク、DevOps-productionへの途中で起こりうるエラー、およびそれらを回避または停止する方法。



Baruch Sadogursky（CA TechnologiesのLeonid Igolnikとともに）は、ビジネスの成長という観点からDevOpsについて語ります。 この報告書は、 「大規模なDevOps：3つの行為におけるギリシャの悲劇」と題されています。 専門家は、会社の成長の各段階で発生する技術的および方法論的困難（従業員数が3人から100人に増加する）、および適切な人員、方法論的および技術的ツールを使用したこれらの問題に対する実証済みの方法および解決策について話します。



完全な会議プログラムと参加条件は、イベントのウェブサイトで入手できます。