定期的なDevOps Enterprise Summitは、2020年6月23日から25日までロンドンで開催されました。 「ロンドン」は、パンデミックがその役割を果たし、会議がオンラインで開かれたため、引用符で囲むことができます。ここには悪い点（ネットワーキングは依然として多くの問題を抱えています）と良い点の両方があります。すべての人から離れてレポートを休憩したり、興味のあるレポートを研究したり、集中したりすることができます-これは非常に便利です...つい最近、私は「チェリャビンスクで」、翌日「ノボシビルスクで」、そして数日後にカリフォルニアでミートアップに参加しました。物理的にこれを行うのは非常に困難です。もちろんレコーディングもありますが、学習する時間を作るという感覚は、学習に役立つようです。
会議レポートの形式はすでにHabréに根付いており、家に座った状態で発展したいという欲求が特に強くなっています（何かをしなければなりません）-そしてここで問題が発生します：多くの会議があります...見たいものをすべて見る方法は？
そして、ここで私は別の形式で会議のレポートを作成しようとすることができると思いました-レポートが何であるかを伝えるためではなく（このため、私は聞いたレポートから個別の「ライブテキストブロードキャスト」を投稿しました）、要約する記事を書きました結論と現在の傾向は、最新の知識をどこに向けるかを示します。
DevOps Enterprise Summitとは何ですか？他の会議とどう違うのですか？
もちろん、DevOpsカンファレンスに関する記事は、DevOpsについての議論から始める必要があります。もちろん、誰もがそれに飽きています。したがって、私は簡潔になるように努めます！
実際、議論する誰もが少なくとも1つのことに同意する可能性があります。「devopsは、ソフトウェアの配信とインフラストラクチャの管理を容易にする一連のプラクティスです」。唯一の違いは、1つのグループ（ほとんどの場合、これらは「管理者」）は「実践の議論は実用的である」と述べ、2番目のグループ（これは開発であり、多くの場合、開発中の管理）は、「これは哲学と方法論である」と信じていることです。 」
「単純化」には怒りが生じるリスクがありますが、本質的には、開発の場合、「管理」メソッドと機能の導入により開発プロセス自体がイデオロギー的に変化し、DevOpsが新しいアジャイルに変わりました。DevOpsに関する経営会議について聞くと、方法論の変更について聞いています。開発。また、DevOps Enterprise Summitは、「管理者」に役立つ会議の1つです。技術に近い報告もありました。
そのため、DevOps Enterprise Summitは2014年から開催されており、IT革命によって、「Project Phoenix」という本で多くの人に知られているGene Kimの創設者と一緒に開催されます。 IT Revolutionは、DevOpsとアジャイルへのリンクに関する一連の本を発表した出版社です。なぜ企業なのか？これは特に重要なポイントです。
小さな会社でアジャイル方法論を導入するのは簡単です。複数人の会社では、最初から存在している可能性が高いので、そのように名前を付けるだけです。数千人、数万人の企業があるため、すべてがはるかに複雑です。それらには膨大な数のプロセスがあり、この巨像が動き続けるように構築されており、これは大型船に例えることができます。船が本土から別の本土に海を渡って移動するとき、それはその役割を果たしますが、船はルートを変更して最短の時間でコースを変更することはできません-これは特にテクノロジービジネスで時間がかかります。ほんの数社の若い会社でも、数千社の会社が何年もかけて構築するであろう数日でプロトタイプを構築できます。したがって、大企業は「若い」技術を変更して使用することを望みますが、プロセスを中断させない方法を理解する必要があります。私はすでに別の記事で例を示しました。Excel1900ではうるう年と見なされます。これは、このようなバグがあったLotus 1-2-3のバージョンとの下位互換性のために行われました。これらのバージョンは80年代にリリースされました。問題は、この互換性を維持する必要があるかどうかです。一般にインターネットから切断されているサーバーの銀行にソフトウェアをインストールする場合、「後で修正する」アプローチでバグはどの程度許容されますか？どのようにして同じ柔軟性を維持できますか？これが会議の目的でした。これらのバージョンは80年代にリリースされました。問題は、この互換性を維持する必要があるかどうかです。一般にインターネットから切断されているサーバーの銀行にソフトウェアをインストールする場合、「後で修正する」アプローチでバグはどの程度許容されますか？どのようにして同じ柔軟性を維持できますか？これが会議の目的でした。これらのバージョンは80年代にリリースされました。問題は、この互換性を維持する必要があるかどうかです。一般にインターネットから切断されているサーバーの銀行にソフトウェアをインストールする場合、「後で修正する」アプローチでバグはどの程度許容されますか？どのようにして同じ柔軟性を維持できますか？これが会議の目的でした。
フォーマット
すべての会議は自分自身をオンラインにする方法を理解しようとしますが、それは興味深いことです。DOESでは、次のことに注意してください。
- レポートは引き続きトラックごとに分割され、視聴者はプロセスの中でトラックを切り替えることができます。
- レポートは会議の前日に記録されました。ブロードキャストに関する技術的な問題を回避するために、レポート中のスピーカーはスラックチャネルにいて、聴衆とコミュニケーションをとっています。これはおそらく私が組織から学んだ最も興味深いものです。解決策は矛盾しています。一方ではインタラクティブが消え、他方では質問のための時間がはるかに長くなります（そして話者がより多くの質問に答える機会が増える）。しかし、例えば、私は主にレポートを聞いていて、ディスカッションに切り替えたくなかったので、最後に来て、残り時間がほとんどなく、次のレポートに新しいスピーカーが来ました。
- , -, .
- , , , , « », - , , , .
- -Horses, -Unicorns — -, « », , — , , .. , - «-» , , ( ) ( Gene Kim).
- DevOps « » — scenius. Scenius «» — genius, , , , scenius, ( Gene Kim). (. medium.com/@stevesargon/steal-like-devops-artist-1-you-dont-have-to-be-a-genius-or-googler-6e9f17c14fb5 Scenius.)
- Platform Engineering, «» «», (DevOps Journey at Adidas III, Exploring Data in the Cloud Fernando Cornago VP, Platform Engineering, Daniel Eichten VP, Enterprise Architecture, Adidas ). (. softwareengineeringdaily.com/2020/02/13/setting-the-stage-for-platform-engineering platform engineering platform team). , , , , . — , , . , , (platform advisory/community management/platform operation/platform evolution).
DevOps Dojo. . , . SRE- Uptime community, , ? Dojo — , , . DevOps- Target, , , , , , , . . youtu.be/1FMktLCYukQ
- Swiss Re — , 156 , DevOps- . , « ». «» — «» CEO, , .. , , , Gartner-, 76% DevOps- «, ». . — , . , «» DevOps- — . . , , : Hermes Germany GmbH , CIO, « », «» .
- , — . State of Devops, Gene Kim Accelerate.
- , , DevOps And Modernization 2.0 (CSG) Scott Prugh — DevOps . , — , : Cobol-, 3,7 IBM High Level Assembler Java ! : .
読む価値のある本：
チームトポロジーの実際、加速：高性能テクノロジー組織の構築とスケーリング。
そして、私はここのブログより少し規則的です、私は自分の電報チャンネルを運営しています、購読してください。