DevOpsForum 2019.デプロイDevOpsは待ちきれません

LogroconがホストするDevOpsForum 2019を最近訪れました。 この会議では、参加者はビジネスと開発および情報技術サービスの専門家との間の効果的な相互作用のためのソリューションと新しいツールを見つけようとしました。







会議は成功しました。本当に多くの有用なレポート、興味​​深いプレゼンテーション形式、そしてスピーカーとの多くのコミュニケーションがありました。 そして、誰も私に何かを売ろうとしていないことが特に重要です。最近の大規模な会議の講演者は罪を犯しています。



RaiffeisenbankのスピーチであるAlfastrakhovanieから、自動化の実装におけるMango Telecomの経験やその他の詳細について説明します。

私の名前はヤナです。私はテスターとして働いています。自動化とDevOpsに携わっており、会議や会議に行くのが大好きです。 過去2年間、オレグブーニンの会議（HighLoad ++、TeamLead Conf）、水差しイベント（Heisenbug、JPoint）、TestConモスクワ、DevOps Proモスクワ、ビッグデータモスクワに参加しました。



まず、会議プログラムに注意を払います。 報告書の内容については、それほどではありませんが、より大きな範囲で、話者に対して説明します。 レポートが非常に技術的で興味深いものであったとしても、社内のレポートからいくつかのベストプラクティスを適用できるということは事実ではありません。 そして、あなたはスピーカーが必要です。

ライファイゼンバンクのパイプラインの終わりに光

通常、私は傍観者の興味深いスピーカーを探しに行きます。 DevOpsForum 2019で、RaiffeisenbankのスピーカーであるMikhail Bizhanが私の興味のある分野に入りました。 プレゼンテーションの中で、彼はどのように着実にチームをDevOpsに配置しているのか、なぜそれが必要なのか、DevOps変革のアイデアをビジネスに売り込む方法を話しました。 まあ、一般的に、パイプラインの終わりに光を見る方法について話しました。





^{ライファイゼンバンクのオートメーションディレクター、ミハイルビザン}



現在、同社には「DevOps」がありません。 つまり、彼は真実ですが、すべてのチームでそうではありません。 DevOpsを実装するとき、彼らは特定のエンジニアの観点と、製品のニーズとこの製品が構築されているプラ​​ットフォームの成熟度の両方の観点から、チームの意欲に依存しています。 ミシャは、DevOpsが必要な理由をビジネスに説明する方法を話しました。



銀行部門にはいくつかの成長ドライバーがあります。サービスのコストと顧客基盤の拡大です。 サービスのコストを上げることはあまり良いドライバーではありませんが、顧客ベースの成長は反対です。 競合他社が客観的にクールな製品を生産する場合、すべての顧客がそこに行き、その後、市場は平等になります。 したがって、市場での新製品の発売とその発売のスピードは、銀行が導く主要なものです。 これがまさにDevOpsの目的であり、ビジネスはこれを理解しています。



次の重要な注意事項：DevOpsは、市場投入までの時間を常に短縮するとは限りません。 DevOpsは単独で動作することはできません。開発から生産まで（コードからクライアントまで）市場で製品を作成して発売するプロセスの一部にすぎません。 ただし、コードの前のすべては、DevOpsと直接関係はありません。 つまり、マーケティング担当者は何年も市場を調査し、一生競争相手に追いつくことができます。 クライアントが必要とするものを迅速に理解し、特定の機能の実装を計画する必要があります。多くの場合、DevOpsが機能し、会社が目標を達成するには不十分です。 したがって、まず、Raiffeisenbankは、DevOpsの使用方法を学ぶ必要があるというビジネスに同意しました。 自動化のための自動化は、新規顧客の闘争にはあまり役立ちません。



一般的に、MishaはDevOpsを実装する必要があると考えていますが、賢明です。 そして、変革の開始時にチームが生産性を失い、収入が減るという事実に備えなければなりませんが、それは実現します。

Mango Telecomのテスト自動化

Mango TelecomのYegor Maslovが、テスターとしての私にとって興味深いレポートを作成しました。 プレゼンテーションのタイトルは「SCRUMチームのテストサイクル全体の自動化」でした。 Egorは、DevOpsはSCRUM専用に作成されたと考えていますが、同時に、SCRUMチームでのDevOpsの実装は非常に問題があります。 これは、SCRUMチームが常にどこかで実行されているため、イノベーションに気を取られてプロセスを再構築する時間がありません。 問題は、SCRUMがサブチーム（テスターのチーム、開発チームなど）を意味しないという事実にもあります。 さらに、既存のプロセスを自動化するためにドキュメントが必要であり、SCRUMにはほとんどの場合ドキュメントがありません。「製品はある種の落書きよりも重要です」。



SCRUMに切り替えた後、テスターは機能のテスト方法について開発者と相談し始めました。 次第に、機能の量が増え、ドキュメントが欠落し、テストカバレッジがなく、一般に誰といつテストしたかが明確ではなくなった機能の多くのバグを見つけ始めました。 一言で言えば-混乱と巻き取り。 テストの自動化に切り替えることにしました。 しかし、その後、完全に失敗しました。 彼らは、通常のテスターに​​は知られていないスタックに書いた自動化の外部委託専門家を集めました。 自動テストフレームワークは確かに機能しましたが、アウトソーシング業者が去った後、彼は2週間生きました。 次に、自己診断テスト2番を導入しようとしました。 それは、すべてが社内で、適切なベクトル：内部の専門知識を高めるために、SCRUMのフレームワーク内で、ドキュメントの作成プロセスで構築する必要があるという事実から始まりました。 自動化のスタックは、製品のスタックと同じである必要があります（ここでは、さらにJavaScriptでプロジェクトをテストしないでください）。 スプリントの最後に、チーム全員が参加して、自動テストがどのように機能するかのデモを配置しました（有用）。 したがって、自動化プロセスへのすべてのチームメンバーの関与が増加し、自動テストへの信頼と、この自動テストが正確に使用される可能性が高まります（また、一定の失敗により1か月以内にコメントアウトされません）。

ちなみに、DevOpsForum 2019ではオープンマイクが機能していました。これは古くから知られている有用な形式のパフォーマンスです。 このように歩き、レポートを聞いてから、会議の枠組み内でトピックや問題について議論し、問題を解決する際に関連する経験を共有する価値があると判断します。



また、主催者が短いレポートのストリームを作成したことにも気付きました。 各レポートは10分以内に終了し、質問が寄せられます。 この方法で、一度に多くのトピックをカバーし、興味のあるスピーカーに質問をせがむことができます。

---

^{報告の合間に、私は会議のパートナーのスタンドを歩き回り、たくさんのものを引っ張った/勝ちました。 ええ、私はrazdatkuが大好きです！}

Alfastrah開発ディレクターとのラウンドテーブルおよびDevOpsに関する質問

私にとってDevOpsForum 2019ケーキの桜は、DevOpsの専門家による1時間の全体会議でした。 4人の参加者が、DevOpsをさまざまな角度から見るために招待されました。専門家、DevOpsをビジネスの観点から見ました）。



専門家は人々の近くに座り、それが始まりました。1時間、聴衆からの参加者が質問をし、専門家は息を吐きました。 時々本当の議論が出ました。 たとえば、DevOpsのエンジニアはまったく必要なのか、なぜシステム管理者から成長できないのか、DevOpsを誰にでも提供すべきなのか、その価値は何なのかなど、質問は大きく異なりました。



それから、アントン・イサニンと個人的に話しました。 DevOps文化をすべての家庭にもたらす必要性について議論し、DevOps変換のダークサイドを明らかにしました。



全員が集まって、製品とビジネスとチームの両方にDevOpsが必要であると決めたと想像してください。 急いで紹介します。 すべてうまくいきました。 吐いた。 DevOpsにより、私たちはクライアントに近づき、彼のすべての要望を迅速に満たすことができました。 その結果、厳しい規制と要件を備えた大規模なOps部門があり、製品の欠陥を常に把握し、多数のアプリケーションを作成しています。 さらに、クライアントが突然ボタンを緑ではなく黄色でペイントしたい場合でも、すべての欠陥には「緊急」のステータスが付きます。 プロジェクトは成長し、リリースの数は増加しています。それに応じて、顧客による新しい機能の欠陥や誤解の数も増加しています。 Opsはさらに10人を雇用して欠陥に対応し、開発者はさらに15人を雇用して欠陥に対応します。 そして、新しい機能を導入する代わりに、チームは無限のSDを使用して、ユーザーに機能を説明し、サポートを説明します。 その結果、Opsと開発の両方が機能していますが、クライアントとビジネスは不満を抱いています。つまり、新しい機能が停止します。 DevOpsはそこにあるように見えますが、そうではないようです。



DevOpsを実装する必要性について、アントンはこれがビジネスの規模に直接依存することを明確に述べました。 1年に1つのクライアントにサービスを提供するだけで10億を超える場合、DevOpsは必要ありません（このクライアントに定期的に新しい変更を展開する必要がない場合）。 すべてがチョコレートです。 しかし、ビジネスが成長すれば、より多くの顧客が現れ、それから私たちはすでに遵守しなければなりません。 原則として、会社には最初はクールなOpsはありません。 最初に製品を見た後、製品が機能することを理解して初めて、サーバーを調べ、配信を監視する必要があります。 その後、Opsが発生します。 Opsは、別のユニットとして、開発に対する多くの障壁を明らかにし始め、すべての配信が停止し始めることを理解する必要があります。 つまり、この場合、DevOpsカルチャはすでに関連していますが、その暗い側面を忘れてはなりません。