DevOpsForum 2019。DevOps の実装が待ちきれません

最近、Logrocon が主催する DevOpsForum 2019 に参加しました。 このカンファレンスでは、参加者は、ビジネス、開発、情報技術サービスの専門家の間で効果的に対話するためのソリューションと新しいツールを見つけようとしました。

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

ライファイゼン銀行、アルファストラホバニー氏の講演からの抜粋、マンゴーテレコムの自動化導入の経験およびその他の詳細。

私の名前は Yana です。テスターとして働いており、DevOps だけでなく自動化も行っており、カンファレンスや交流会に行くのが大好きです。 過去 XNUMX 年間、私はオレグ ブニンのカンファレンス (HighLoad++、TeamLead Conf)、Jug イベント (Heisenbug、JPoint)、TestCon モスクワ、DevOps Pro モスクワ、ビッグ データ モスクワに参加してきました。

まず第一に、カンファレンスのプログラムに注目してください。 私はレポートの内容よりも、講演者に注目しています。 たとえレポートが非常に技術的で興味深いものであることが判明したとしても、そのレポートのベスト プラクティスの一部を社内に適用できるかというと、そうではありません。 それからスピーカーも必要です。

ライファイゼンバンクのパイプラインの終点に光が灯る

通常、私はサイドラインで興味のある講演者を探しています。 DevOpsForum 2019 で、ライファイゼン銀行の講演者であるミハイル・ビザン氏に興味を惹かれました。 講演の中で、彼はチームがどのようにして徐々に DevOps に夢中になってきているのか、なぜ DevOps が必要なのか、そして DevOps 変革のアイデアをビジネスに売り込む方法について話しました。 さて、私は一般的に、パイプラインの終わりにある光を見る方法について話しました。

Mikhail Bizhan 氏、ライファイゼン銀行オートメーション担当ディレクター

現在、彼らの会社には「DevOps」はありません。 つまり、彼は働いていますが、すべてのチームで働いているわけではありません。 DevOps を実装するときは、特定のエンジニアの点と、製品のニーズおよびその製品が構築されるプラットフォームの成熟度の両方の点で、チームの準備状況に依存します。 Misha 氏は、DevOps が必要な理由を企業に説明する方法を説明しました。

銀行部門には、サービスのコストと顧客ベースの拡大など、いくつかの成長要因があります。 サービスのコストの増加はあまり良い推進力ではありませんが、顧客ベースの拡大はその逆です。 競合他社が客観的に優れた製品をリリースすると、すべての顧客がそこに流れ、時間が経つにつれて市場は横ばいになります。 したがって、銀行が主に注力しているのは、新商品の市場への導入とその導入のスピードです。 これはまさに DevOps の目的であり、企業はこれを理解しています。

次に重要な点は、DevOps によって市場投入までの時間が必ずしも短縮されるわけではないということです。 DevOps は単独で機能するものではなく、開発から実稼働 (コードから顧客へ) まで、製品を作成して市場に投入するプロセスの一部にすぎません。 ただし、コードより前の部分はすべて DevOps に直接関係しません。 つまり、マーケターは何年も市場を研究し、競合他社に追いつくために一生を費やすことができます。 クライアントが何を必要としているのかを迅速に理解し、特定の機能の実装を計画する必要があります。多くの場合、これだけでは DevOps が機能し、企業が目標を達成するには不十分です。 したがって、ライファイゼンバンクはまず、DevOps の使用方法を学ぶ必要があるという点で企業側に同意しました。 自動化のための自動化は、新規顧客獲得の戦いにはあまり役に立ちません。

一般に、ミーシャは DevOps は賢明に実装する必要があると考えています。 そして、変革の初期にはチームの生産性が低下し、収入も減りますが、その後はそれが正当化されるという事実に備える必要があります。

Mango Telecom におけるテストの自動化

テスターとしての私にとってもう XNUMX つの興味深いレポートは、Mango Telecom の Egor Maslov によって提供されました。 このプレゼンテーションは「SCRUM チームにおける完全なテスト サイクルの自動化」と呼ばれていました。 Egor 氏は、DevOps は SCRUM のために特別に作成されたものであると考えていますが、同時に、SCRUM チームに DevOps を導入することには非常に問題があります。 これは、SCRUM チームが常にどこかで実行されており、イノベーションに気をとられてプロセスを再構築する時間がないために発生します。 問題は、SCRUM がチーム内のサブチーム (テスト チーム、開発チームなど) の分離を伴わないという事実にもあります。 さらに、既存のプロセスを自動化するにはドキュメントが必要ですが、SCRUM では完全にドキュメントが存在しないことがほとんどです。「製品は何らかの文書よりも重要です。」

SCRUM に切り替えた後、テスターは機能をテストする方法について開発者と相談し始めました。 徐々に機能の量が増加し、ドキュメントはなくなり、テストでカバーされなかった機能の多くのバグが見つかり始め、一般に誰がいつテストしたかが明確でなくなりました。 一言で言えば、混乱と動揺です。 私たちはテストの自動化に切り替えることにしました。 しかし、それでも完全な失敗がありました。 彼らは、社内のテスターが知らないスタックに書き込む外部委託の自動化専門家を雇いました。 もちろん自動テストのフレームワークは機能しましたが、アウトソーシング業者が去った後も XNUMX 週間続きました。 次は自動テストその XNUMX を導入する試みでした。 それは、SCRUM のフレームワーク内ですべてを社内で独自に構築し (正しいベクトル: 社内で専門知識を構築する)、そのプロセスでドキュメントを作成する必要があるという事実から始まりました。 自動化のスタックは製品のスタックと同じである必要があります (ここではそれを追加しています。他のもので JavaScript プロジェクトをテストしないでください)。 スプリントの最後に、自動テストがどのように機能するかをチーム全体でデモしました (役に立ちました)。 したがって、自動化プロセスへのすべてのチーム メンバーの関与が増加し、自動テストに対する信頼と、この自動テストが確実に使用される (そして、失敗が絶えないため XNUMX か月以内にコメントアウトされない) 可能性が高まりました。

ところで、DevOpsForum 2019 では、オープン マイクが開催されました。これは、長い間知られており、私の意見では、便利なスピーチ形式です。 このように歩き回り、報告を聞き、会議で特定のトピックや問題について話し合う価値があると判断し、問題解決に関連する経験を共有します。

主催者が短いレポートを次々と作成していることにも気づきました。 各報告は 10 分以内で終了し、その後に質問が続きます。 こうすることで、一度に多くのトピックを取り上げ、興味のある講演者に質問することができます。

プレゼンテーションの合間に、私はカンファレンスパートナーのブースを歩き回り、たくさんのものを盗んだり勝ち取ったりしました。 ああ、配布資料は大好きです！

Alfastrakhovanie の開発ディレクターとのラウンド テーブルと DevOps の問題

私にとって、DevOpsForum 2019 の華を添えたのは、DevOps 専門家による XNUMX 時間の全体セッションでした。 セッション参加者として、Anton Isanin (Alfastrakhovanie、開発ディレクター)、Nailya Zamashkina (Fintech Lab、オペレーティング ディレクター)、Oleg Egorkin (Rostelecom、アジャイル コーチ)、Anton Martyanov (独立専門家、DevOps を考察) の XNUMX 人がさまざまな角度から DevOps を考察するよう招待されました。ビジネスの観点から）。

専門家が人々の近くに座ると、事態が起こり始めました。丸一時間、聴衆の参加者が質問し、専門家がラップを披露しました。 時には真剣な議論もあった。 たとえば、DevOps エンジニアはそもそも必要なのか、システム管理者としてのトレーニングを受けられないのはなぜなのか、DevOps はすべての人に提供されるべきなのか、その価値は何なのかなど、質問はさまざまでした。

それから私はアントン・イサニンと個人的に話しました。 私たちは、DevOps 文化をすべての家庭にもたらす必要性について話し合い、DevOps 変革の暗い側面を明らかにしました。

全員が集まり、DevOps が製品、ビジネス、チームの両方に必要であると決定したと想像してください。 実装してみましょう。 すべてがうまくいきました。 私たちは息を吐きました。 DevOps のおかげで私たちはクライアントに近づくことができ、今ではクライアントのすべての要望をすぐに実現できるようになりました。 その結果、当社には厳格な規制と要件を備えた大規模な運用部門があり、常に製品の欠陥が見つかり、大量のリクエストが作成されています。 さらに、クライアントが予期せずボタンを緑色ではなく黄色にしたい場合でも、すべての欠陥には「緊急」ステータスが割り当てられます。 プロジェクトは成長し、リリースの数も増加しており、それに応じて、クライアントによる新しい機能の欠陥や誤解の数も増えています。 運用部門は欠陥の報告に対応するためにさらに 10 人を雇用し、開発部門は欠陥のクローズに対応するためにさらに 15 人を雇用します。 そして、新しい機能を導入する代わりに、チームは無限の SD を使用して、ユーザーに機能を説明し、同時にサポートします。 その結果、運用と開発は両方とも機能していますが、クライアントとビジネスは不満を抱いています。つまり、新しい機能が行き詰っています。 DevOps は存在するようで存在しないことがわかります。

DevOps実装の必要性について、アントン氏は、これはビジネスの規模に直接依存すると明言した。 年間 XNUMX 人のクライアントにサービスを提供することで会社に XNUMX 億ドルがもたらされる場合、DevOps は必要ありません (このクライアントに新しい変更を定期的にロールアウトする必要がない場合)。 すべてがチョコレートで覆われています。 しかし、ビジネスが成長し、より多くの顧客が現れた場合は、従う必要があります。 原則として、最初は社内に優秀な運用担当者はいません。 まず製品を切断し、そのとき初めて、製品が機能するためにはサーバーとモニターの電源に注意を払う必要があることがわかります。 そこでOpsが登場します。 運用部門が独立した部門として、開発に対して多くの障壁を築き始め、すべての納品が停滞し始めることはまだ理解されていません。 つまり、この場合、DevOps 文化はすでに関連性を持っていますが、その暗い側面を忘れてはなりません。

出所： habr.com