DevOpsDays モスクワ カンファレンス レビュー: 6 つのレポートからの洞察

第7回会議はXNUMX月XNUMX日に開催されました。 DevOpsDays モスクワMail.ru Cloud Solutions のサポートを受けてモスクワ DevOps コミュニティが主催します。主要な DevOps 実践者によるプレゼンテーションに加えて、参加者は短いモチベーションを高めるライトニングトーク、ワークショップに参加し、オープンスペースでネットワーキングを行うことができました。

私たちは 6 つの講演から重要な洞察を集め、講演以外の内容についてさらに詳しく知るために数人の講演者にインタビューしました。

内側：

1. Baruch Sadogursky、JFrog: 「ソフトウェアをベンダーからユーザーへ液体のように流しましょう」
2. サウスブリッジのパベル・セリバノフ氏：「開発と運用には共通のタスクが 1 つあります。それは、機能する製品を作ることです。」
3. Vladimir Utratenko、X5 Retail Group: 「エンタープライズにおける DevOps は、苦労や問題のない開発です」
4. セルゲイ・プジレフ、Facebook：「プロダクションエンジニアはサービス全体を気にかけます。ユーザーと開発者の両方が満足できるように。」
5. AMBOSS の Mikhail Chinkov 氏: 「DevOps の道は 1 つの部門だけでは実現できません。会社全体で実現する必要があります。」
6. Rosbank DevOps 愛好家: 「血まみれの企業に DevOps を実装する 1000 日」

1. JFrog の Baruch Sadogursky 氏: 「ソフトウェアをベンダーからユーザーへ液体のように流しましょう」

ソフトウェア更新の失敗は毎時間、誰にでも起こります。講演で聞いた恐ろしい話の一つを紹介しよう。Knight Capital はアップデートの失敗により 440 時間で XNUMX 億 XNUMX 万ドルを失った。

Baruch 氏は、障害やユーザーの嫌悪感を回避するのに役立つ継続的な更新の DevOps パターンについて語りました。

ローカルロールバック — 必要に応じてロールバックできるように、デバイスにソフトウェアの以前のバージョンを保存しておきます。これにより、状況が悪化してパッチを無線で送信できなくなった場合でも保護されます。

無線アップデート - 連続したものの方が良いです。そうでなければ、ジャガーの開発者と同じことになるでしょう。無線で更新できなかったブレーキシステムのバグのために、彼らは車を販売から回収しなければなりませんでした。それは痛くて高価でした。

継続的なアップデート - 新しい機能が準備でき次第、ソフトウェアを継続的に更新します。更新がまれな場合、機能はグループ化されます。重要でないものは重要な更新を待つことができます。テスラと同様に、ランダムな速度低下を修正するはずだったアップデートは、チェス ゲームのアップデートを待っていました。

自動展開 - 人間は定型的なタスクを実行するのが苦手なので、人間を機械に置き換える。

頻繁な更新 - 習慣を身につけ、恐​​怖を取り除くのに役立ちます。まれなアップデートが緊急事態に変わります。

デバイスの状態を知る - 最初からインストールするのではなく、更新をテストします。デバイスの状態に応じて更新の動作が異なる場合があるため、これは重要です。

カナリアリリース - 少数のユーザーに更新を展開し、観察します。これにより、何か問題が発生した場合の被害が軽減されます。

利用不可のないアップデート — 顧客が新機能に気づくだけで、アップデートを展開している間、数週間にわたってサービスを受けられない状態にならないようにします。

私たちは、ロシアと西側の IT における DevOps の考え方の違い、クラウドがすぐにすべてを行うようになるかどうか、すべてのソフトウェア サービスが aaS スキームに組み込まれるかどうかについて、Barukh Sadogursky 氏に話を聞きました。インタビューをご覧ください。

2. サウスブリッジのパベル・セリバノフ氏：「開発と運用には共通のタスクが XNUMX つあります。それは、機能する製品を作ることです。」

Kubernetes を実装しても DevOps の実現には役立ちません。逆に、すべてが壊れてしまう可能性があります。 Pavel 氏は、テクノロジー (どんなに優れたものでも) がすべての問題を解決できるわけではない理由を次のように説明しました。

プロジェクトの複雑さはコードの範囲を超えている。以前は、複雑なアプリケーションがありました。プロジェクト内のやり取りと複雑な開発ですが、構造はシンプルで、管理者がそれを展開すればすべてが機能します。私たちはマイクロサービスに移行しました。各サービスはシンプルなアプリケーションであり、標準プロトコルを介して通信し、開発が迅速になりましたが、プロジェクト構造はより複雑になりました。マイクロサービス アーキテクチャを使用したプロジェクトの複雑さは解消されたわけではなく、コードを超えた問題になっています。現在はDevOpsエンジニアが担当しています。

開発者はDevOps導入後の変更を望まない。その結果、Kubernetes ワークフローは、Dev から Ops に壁越しにタスクを投げているように見えますが、もはや比喩的なものではなく、Git がその壁になります。開発者はそこにコードを配置して以前と同じように作業し、管理者は Kubernetes、CI/CD、その他すべてを使用します。

ただし、開発者は変更を受け入れる必要があります。。開発者が管理者の作業を知らない、管理者が開発者の作業を知らないという状況では、問題が発生します。

開発者にとって何も変わっていない場合、アプリケーションの操作は開発者の責任であることを認識していないため、さまざまな技術的なトリックは機能しません。

DevOps と Kubernetes の登場により、開発には多くの変化が起こります。開発者は運用に精通している必要があり、その逆も同様です。これらの専門家はそれぞれ独自のスキルを持っていますが、お互いの仕事を認識している必要があります。 Kubernetes を実装する前に、Dev と Ops が友好関係を築く必要があります。そうしないと、既存のシステムが壊れてしまいます。

Pavel Selivanov 氏は、Kubernetes が今後 5 年でどうなるか、そして現代のスタートアップがテクノロジー スタックを何に基づいて構築すべきかについて語りました。インタビューをご覧ください。

3. Vladimir Utratenko、X5 Retail Group: 「エンタープライズにおける DevOps は、苦労や問題のない開発です」

企業は、開発が遅すぎて現実に即していないことに気づき、より優れた開発とより迅速な展開を希望して、DevOps 変革に取り組みます。

ウラジミールは、これがどのように起こるのか、そして何が問題なのかを次のように説明した。

1. まず、企業は DevOps エンジニアを雇用します。この上級システム管理者は、リリースの運用環境への展開、開発環境の標準化、インフラストラクチャの設定、さまざまな問題の検出と修正、プロセスの自動化、その他の技術的なタスクに従事しています。
2. すると、DevOps エンジニア 1 名では不十分となり、会社は DevOps チームを雇用することになります。これは、さまざまなエンジニアの努力を組織化し、1 つの方向に集中できるようにするコンピテンス センターです。
3. 実際、DevOps エンジニアと DevOps チームは、DevOps 変革のアンチパターンです。 DevOps は実践と文化に関するものであるため、テクノロジー企業 (SRE、プロダクション エンジニアリング) でも DevOps が実装されています。

私たちは何をすべきでしょうか? DevOps 変革の実装、実践の実行、開発文化とテクノロジー文化の育成を支援する一時的な DevOps チームを雇用します。

企業が参入し、DevOps に投資すると、いくつかの結果が考えられます。離陸時にすべてが崩壊するでしょう。 SRE/プロダクションエンジニアリングまたは組み込みオペレーションとして残ります。プロセスがビジネス メトリックに基づいている BizOps に移行します。

Vladimir Utratenko 氏は、企業における DevOps が実際どれほど「重要」であるか、また大手小売業者内でどのように実践されているかについて語ってくれました。インタビューをご覧ください。

4. セルゲイ・プジレフ、Facebook：「プロダクションエンジニアはサービス全体を気にかけ、ユーザーと開発者の両方が満足できるように努めます。」

Facebook は、多数のコンポーネント、サーバー、人材、データ センターを備えた巨大な企業です。サイズは大きいですが、非常に高速であるため、開発者は 1 日に何度もサービスを展開できます。 Facebook も急速に成長しており、ユーザー数やサーバー数だけでなく開発者の数も増えているため、状況はより複雑になっています。

セルゲイは、Facebook でのプロダクション エンジニアの仕事について次のように説明しました。

1. プロダクション エンジニアは大量のコーディングを行うため、オペレーティング システム、ファイル システム、データベース、ネットワークなどのシステム知識が必要です。分散システムおよび信頼性エンジニアリング（製品の信頼性のサポートなど）の作業経験が必要です。オンコール、つまりいつでも呼び出し可能な状態である必要があります。
2. プロダクション エンジニアは、高度な運用スキルにおいてソフトウェア エンジニアとは異なりますが、本質的にはソフトウェア エンジニアのサブタイプです。ソフトウェア エンジニアはより多くのコードを記述し、たとえばデータ処理に関連する追加のスキルを持つ場合があります。 Facebook では、こうした専門家も待機しなければならないが、これは多くの人にとって不愉快な驚きである。
3. 企業における製造エンジニアのニーズピラミッドは、サーバーとそのライフサイクルの監視、つまり新しいハードウェアの受け取り、セットアップ、運用開始から始まります。次のレベルはサービス レベルで同じで、サービスとそのライフ サイクルを監視します。次に、シームレスなスケーリングと高度な監視が行われます。自動スケーリングは、サービス ライフサイクルが自動化された後に使用されます。そして最終的には、スケーリングが効果的になり、会社がコストとリソースを節約できるように、何らかの調整を行う必要があります。

5. ミハイル・チンコフ、AMBOSS：「DevOps の道は XNUMX つの部門だけで進むべきではありません。会社全体で従う必要があります。」

ミハイルは、DevOps は継続的な開発であると信じています。いくつかのツールを実装してそれで終わりというわけにはいきません。企業が DevOps に移行するのを妨げている問題は何ですか? また、その実践方法を教えてください。

DevOps の理解の違い。福音派が考える標準的な DevOps は、次の 5 つの柱に基づいています。

• 文化 - 人とコラボレーションに重点を置く。
• 自動化 - 日常的なタスクをワークフローに委任する。
• 無駄を省く - ユーザーに価値を提供することに重点を置く。
• 共有 - 知識の継続的な交換。
• 指標を作成し、その助けを借りてフィードバックを得ます。

企業は通常、自動化とユーザーへの価値提供のみに重点を置いています。しかし、文化、知識の共有、進捗状況を追跡するための DevOps メトリックは背景に押しやられています。

DevOps標準化の課題。製品の目標は企業ごとに異なり、標準化することはできません。企業における DevOps の状況は企業自体によって異なりますが、多くの人はこれを理解せず、DevOps エンジニアを雇用すれば十分だと考えています。

なぜまだ DevOps を導入していないのでしょうか? 重要な問題が 2 つあります。企業では、組織の発展が遅く、何千人もの従業員の心のベクトルを変えるのが困難です。スタートアップでは、知識源が不足しており、変革のためのリソースの割り当てに問題があります。

企業におけるDevOps開発の段階:

• 1 つ目は、インフラストラクチャはクラウド内にあるものの、1 人か 2 人の管理者を除いて、その仕組みを誰も知らないことです。
• 2 つ目は、インフラストラクチャはすべてのエンジニアにとって透明で理解しやすいものの、プロセスが合理化されていないことです。
• 3 番目 - エンジニアがライブ サービスを独自に起動および修復します。
• 4 番目 - エンジニアはコア インフラストラクチャに自発的に貢献し、クラウド内のコードは透過的になり、ボタンを押すだけで展開されます。

理想的な設定は、誰もがインフラストラクチャに平等にアクセスでき、すべてのエンジニアが製品にアクセスして、何をしているのか理解していることです。

すべての文化的および技術的なゲシュタルトを閉じることにより、同社の DevOps 変革はビジネスおよびプラットフォーム指標からのフィードバックを考慮に入れることになります。

6. Rosbank DevOps 愛好家: 「血まみれの企業に DevOps を実装するには 1000 日かかります」

Rosbank の Yuri Bulich、Dina Maltseva、Evgeniy Pankov が、3 年間で DevOps に至った経緯を語りました。目標は 2 つありました。特定のチームの特定の問題を解決することと、集中化されたツールを実装することです。

達成された結果は次のとおりです。

製品チームの結果: 組み立てが 30 倍、設置が 6 倍高速化され、サイクル全体で最大 30% の節約が実現します。ボタン一つで生産を開始できるようになりました

プラットフォームチームの結果: 組み立てと設置が 10 倍速くなり、設置数が 87% 増加し、自動テストの範囲が 46% になりました。統合チームはもはやボトルネックではない

では、企業で DevOps プラクティスをどのように実装すればよいのでしょうか?

まずパイロットプロジェクトを実施するチームを選択し、アーキテクチャの実装方法を決定し、ツールを選択します。私たちは、オープン ライセンスを持ち、銀行内でインストールが可能で、その使用に関する専門知識を備えたツールを選択しました。 Rosbank は DevOps プラットフォームと同時にプライベート クラウドを導入し、これが当初は役立ちました。クラウドでは、ボタンを押すだけで 15 分以内に必要なリソースを取得することができました。以前は、このようなプロセスには XNUMX 週間かかることもありました。

銀行やその他の企業では、情報セキュリティ チームと事前に制限事項を検討し、変更を実施できるソリューションを見つける必要があります。

パイロットの後、成功したソリューションを拡大する必要がある.

1. コンベアをできるだけ「まっすぐ」にし、不要なリンクを排除し、価値のあるサプライヤーを特定し、残りのコンポーネントを取り除くことが重要です。中間リンクはアンチパターンです。たとえば、ロスバンクでは、多くのチームで内部開発がうまくいかず、外部開発だけが残っていました。これにより、外部開発者から内部開発者へのコード転送を容易にする専用の DevOps チームが結成されました。この問題は、外部開発を CI/CD に統合することで解決されました。これにより、銀行はコードを自社から銀行に転送するだけでなく、その成功に対しても責任を負うようになりました。
2. 成熟度モデルには、DevOps プラクティスの要素が含まれ、ツールがリストされ、外部サプライヤーとの連携の詳細が考慮されました。これにより、新しいチームに実装する際に、タスクのバックログを迅速に削減するのに役立ちました。
3. ソフトコントロールと推奨の形でのガバナンスが必要です。優れた DevOps ハンドブックは、チームがプラットフォームを正しく使用するのに役立つ組織的およびツール的特性のセットです。
4. 今すぐに文化に注意を払う価値はあります。そうすれば、多くの変化がより速く、より簡単に起こるでしょう。社内コミュニティを成長させ、ミートアップ、技術ワークショップ、トレーニング、楽しいアクティビティを開催します。これは成果をもたらします。つまり、人々は実践を共有し、誰が何をしたかを確認し、どこに頼ればよいかを知り、会社内に熱狂と健全な競争が生まれます。
5. プロセスに関与していない人や、十分に成熟していないチームと協力するのは意味がありません。関心のあるチームや忠実な人々に投資する方がよいでしょう。
6. 選択されたソリューションは、それを使用するエンジニアにとって便利なものでなければなりません。
7. 外部開発は障害ではありません。そこでも実践を実施できますが、重要なのはチーム自体がその意欲を持っていることです。

もう少しだけメリットを

Alexander Chistyakov (vdsina.ru) による、DevOps 関係者にとって読む価値のある書籍のリスト:

1. イリーナ・ヤクテンコ「意志と自制心」
2. ダニエル・カーネマン「ファスト＆スロー」
3. バーバラ・オークリー「数字に対する心」
4. マキシム・ドロフェエフ「ジェダイのテクニック」。
5. ヴィクトール・フランクル「夜と霧」。

乞うご期待

私たちも DevOps が大好きです。エピソードの発表をお楽しみに 開発者 および @Kubernetes やその他の Mail.ru Cloud Solutions イベントについては、Telegram チャンネルをご覧ください。 t.me/k8s_mail

出所： habr.com