会議の組織には独自の「開発者」と「運用者」がいます。成功するには、優れたレポートからプログラムを「開発」し、「販売のために展開」する必要があります。 また、新しい会議では、新しいソフトウェア製品と同様に、両方の段階で多くの問題が発生する可能性があります。 DevOopsを初めて実施しました-そこで何が起こったのですか？ 参加者の1人からの回答がすでにHabréに掲載されており、現在テキストを公開しています。
待っている困難の中には、例えばそのようなものがあります。 会議の会場を選択するとき、観客の数から進む必要がありますが、そのような会議が以前に開催されていない場合、この数を予測する方法は？ 実際の需要は、サイトがほとんど空のままであるか、継ぎ目でクラックするように、はるかに低いか高いことが判明しますか？ スタートアップの永遠の問題は「依存する負荷」です。 しかし、最終的には、ある種の致命的な不一致は発生せず、クラウンプラザの会議施設は集まった何百人もの人々にやってきました。
しかし、会議中に、ボリュームマッチングの別の問題が発生しました。 開会式とそれに続くCorey Quinnの基調講演は、当初の予想よりも時間がかかりませんでした。したがって、Coreyが講演を終えたとき、スケジュールに従って、まだかなりの時間が残っていました。 しかし、これはそれほど怖いことではありません。スピーチの後、スピーカーは特別なディスカッションエリアに移動しました。そのため、スピーカーからもっと多くを得たい場合は、常にそこで行うことができます。 また、Coreyはこのゾーンへの関心の欠如について文句を言うことはできませんでした。
Corey Quinnの場合の「ops-part」がうまく機能しなかった場合、「dev」ではすべてが異なっていました。パフォーマンス自体は素晴らしいレビューを受け、ホールで繰り返し笑い声を上げました。 Coreyは、大企業が唯一の真のインフラストラクチャとしてインフラストラクチャについて語り、残りの人々が口にしたときの状況を皮肉的に批判しました。 彼の意見では、これは貨物カルトに似ており、人々は「すべてがうまく機能している」と見て、内部の違いを考慮せずに同じ成功を当てにして外部の兆候を模倣します。
「Netflixのスピーカーがステージから言ったのを見ました。「すべての開発者が製品にアクセスできるようにします。」 聴衆の誰もが感銘を受け、私の隣の人は言った：「はい、開発者に製品へのアクセスも与えるべきです。」 私は彼のバッジを見て、彼が銀行で働いているのを見ました！ 聞いて、コンテキストを考慮に入れる必要があります。 第一に、Netflixは後輩を受け入れないことに誇りを持っています。もちろん、誰もが経験を積んだときに簡単にアクセスできるようにします。 第二に、彼らは市場よりも上に支払います-そして誰もが「Netflixのようになりたい」と望んでいますが、何らかの理由で彼らは市場よりも上に支払いたいとは思いません。 第三に、Netflixのあらゆる規模で、彼らは単に映画をストリーミングします。 映画が始まらない場合、銀行の破綻が発生したような大規模な問題にはなりません。」
基調講演の後、アクションはさまざまな部屋に分かれ、さまざまなトピックが始まっただけでなく、「devoops-report」の概念に対するさまざまなアプローチがどのように始まったかを見ることができました。 JokerからHeisenbugまでの他の会議は、「ハードコア」な性質で知られています。レポートは「一般的なおしゃべり」ではなく、技術的な仕様です。 しかし、DevOpsでは、プログラム委員会のメンバーであるBaruch jbaruch Sadogurskyが以前インタビューで指摘したように、すべてがより複雑です。 この場合、「プロセス」、「人」、および「ソフトスキル」がJava会議で見たであろう他のすべてが最も重要なコンポーネントであることがわかり、DevOpsの問題をDockerで大騒ぎするだけで減らすことはできません。 それでは、プログラムは何をするのでしょうか？ 通常、レポートのレビューに多くの注意を払って、次に視聴者に何を提供するかをよりよく理解しますが、ここにはまだレビューがないため、リスクを取る必要がありました。 その結果、DevOopsにはさまざまなオプションがありましたが、どのオプションが視聴者により適しているかは、レビュー後にのみ最終的に理解することができました。
最初のタイムスロットでは、まったく異なるレポートを見ることができました。 エイドリアンコールはZipkinを使用した分散トレースについて話し、同じBaruchは Leonid Igolnikとともに、正しい義務はどうあるべきかについて話しました。
最初のケースでは、まさにその技術的な詳細でした。 エイドリアンは、「トレース」、「ロギング」、「メトリック」の概念を比較することから始め（他の誰かのブログ投稿からの視覚的な図を参照）、後にジプキンに直接行き、理論的にそれについて話し、実際にその使用を実証しました。 彼のスピーチの中で多少抽象的な抽象的な事実は、ジプキンがそう呼ばれている理由だったようです。 Twitterが定期的にクラッシュしていわゆる「クジラの失敗」を示したとき、Zipkinはこれに対抗するために作成され、トルコ語の「har」を意味する言葉を使用しました（つまり、「クジラを殺すのに役立つ」）。
しかし、バルークとレオニードのパフォーマンスは完全に異なっていました。 そこにはログを操作するための適切なツールの価値が言及されていましたが、多くの場合、エスカレーションパスのようなものについてでした。問題を解決するための自分の能力が十分ではなくなったときに従業員が誰とどのような条件で勤務し続けるべきかということです。 もちろん、これはテクノロジーに関するものではありません。もちろん、レポートにはジョークがたくさんありました（バルークと別の人を待つのはおかしいでしょう）-しかし、この「一般的なおしゃべり」と呼ぶこともできません。 さらに、いくつかのことはばかげていて重要でした。「エスカレーションパスが会社のCEOに届くのはなぜですか。 まず、練習では、5〜6時間以内に監督を起こさなければならない場合、さらに多くの問題はこれら5〜6時間で解決する時間があることを示しています。
そして、2つのオプションのうち、視聴者にとって興味深いものはどれでしたか？ 笑う：これら2つのレポートの視聴者評価の加重平均の差は約300分の1であり、これは統計的エラーと見なすことができます。 そして、どちらも会議レポートのトップ5に入りました。 このような成功により、視聴者が両方に興味を持っていることは明らかです。
ただし、これら2つのレポートの違いはすべて共通しています。技術ツールであろうとワークフローであろうと、会社に直接実装できるものに関するものです。 また、「プロジェクトを変更する方法に関する直接的な指示はありませんが、知っておくと良い」などのレポートもあります。このようなものはありましたか？ はい：例えば、 Oleg m0nstermind Anastasievが、同じサーバーで複数のタスクを同時に実行できる場合、Odnoklassnikiが「各サーバーは1つのタスクのみを担当する」という分離から「プライベートクラウド」に移行した方法に関するストーリーです。 彼らの1クラウドソリューションはオープンソースではないため、自宅で使用することはありませんが、他のロジックに従って、全員に共通の原則をよりよく理解できます。 最小の応答時間を必要とするタスク、条件付きの「大隊」が多くのリソースを必要とするタスク、および他のタスク（「バックグラウンド」）が順番を待つことができる場合、CPUリソースをタスク間で正しく分割する方法、およびDocker起動パラメーターはこれを支援しますか？ しかし、Dockerに分離のための適切なパラメーターがまったくないトラフィックについてはどうでしょうか。
同僚、上司、その他の無関心な人に「DevOpsを販売する」ラウンドテーブルは好奇心が強いことが判明しました。 開発と管理の両方の「技術」関係者の場合、市場投入までの時間の加速や他の指標を示す特定の指標に基づいて休むことができるようです。 しかし、対話の中で、これらの双方の円卓会議参加者は、仕事のセキュリティに関連する懸念があることに気づきました：管理者は彼らが必要とされず解雇されることを恐れており、開発者は生産を中断し解雇されることを恐れています。 同時に、人々はそのような恐れを声に出して表現することはできませんが、恐れが払拭されるまで技術的な議論を始めるだけです。 そして、DevOpsを正常に構築するためには、Kubernetesを理解することと同じくらい重要なのは、人々を理解することです。
しかし、もちろん、Kubernetesを理解することも重要です-彼についてのいくつかの報告が一度にあり、ほとんどの聴衆はニコライリジコフのパフォーマンスを高く評価しました。 ここには継続的な技術仕様がありました。「ConfigMapsやSecretsなどのリソースが多数あります。これは、Postgresパスワードなど、コンテナにマウントして転送できる純粋な情報リソースです。 これを、起動時にコンテナに注入される環境変数に関連付けることができ、ファイルシステムにマウントできます。すべてが便利です。
最後に、会議は「ギリシャの悲劇」と定型化されたバルーク・サドグルスキーとレオニード・イゴルニクの基調講演によって完了しました（舞台に花瓶があり、スピーカーがトーガにいたという事実まで）。 しかし実際には、それはむしろコメディでした：さまざまなDevOpsの問題（ 左パッドのストーリーからGitLabのストーリーまで ）に直面する架空の会社の不運を乗り越えて、聴衆全体が定期的にighしています。 ここでは、職務に関する報告書のような具体的な実際的な結論はありませんでしたが、これは閉会のスピーチでは要求されませんでした。 その結果、誰もが喜んでおり、「悲劇」が視聴者レビューのヒットパレードをリードしました。 レビューで述べたように、バルークは常にカリスマ性がありますが、レオニードとは一般的に相乗効果があります-これらは2つの完全に補完的なスピーカーです。
結果は何ですか？ 最初の生産テストは、いくつかの小さな困難にもかかわらず、一般的には正常に完了しました。 しかし、devopsに関連する人なら誰でも知っています。1つのリリースをリリースすることは1つのことであり、定期的な更新で継続的デリバリーを適切に構築するようにしてください。 さて、試してみましょう。最初のDevOopsが成功したので、2番目のDevOopsの外観を渡さないでください。
