DevOops 2017：方法とDocker、Docker、Docker

2017年10月20日サンクトペテルブルクで開催されたDevOpsカンファレンスに参加し、印象を説明しました。 「5日間で会社にDevOpsを実装する方法」の精神で筋金入りの実際の例や、Dockerの無限の熱狂に頼らないでください。







組織は最高レベルでした。コーヒークッキーで十分です。 登録待ちのキューはなく、目立つ場所にサインします。 ポップコーンも含め、必要なものはすべて提供されました。 レポートは3つの部屋に配布され、最初と最後の部屋のみが1つの（最初の）部屋で開催されました。 これは重要なポイントです。最初の行為では、なぜ私がそれに注意を払ったのかが明らかになります。

第1段階：Corey Quinn、Docker、および本番環境のルート

会議自体は、Netflix、Google、AWSについてのCorey Quinnの講演から始まりました。 報告書は英語であり、ジョークに対する聴衆の反応により、かなりの人がそれが何であるか理解していないことが明らかでした。 これは主催者の数少ない間違いの1つであり、翻訳せずに英語で最初のレポートを作成する価値はありませんでした。 レポート自体は興味深いものでしたが、技術的な詳細はありませんでしたが、コーリーは一般的なアプローチについて説明しました。



簡単に要約すると、Netflixは開発者が本番のルートを持っているという点で、古典的なDevOpsを持つ会社です。 はい、はい、そのような会社があり、安全に働いています。 魔法はありません、彼らは最高の最高のものだけを雇う余裕があるだけのお金を持っています。 基本的に後輩はいません。



コーリーは彼のキャリアの初期から重要な話をしました。 彼は後輩であり（Netflixで働いていなかったことを意味します）、ある日、深刻な間違いを犯しました（phakap-私はこの記事での使用を禁じられていました）。 翌日、結果が取り除かれたとき、リーダーは彼に電話をかけ、彼らは対話をしました：



-昨日生産を中断しました。

-はい、私はそれを壊しました、これは私の間違いです。 非常に重要なデータを削除しました。

「間違いが何であったか理解できますか？」 これが再び起こらないようにするために何が行われましたか？

「はい、間違いは...完了しました...」

-はい、仕事に行きます。



コーリーは、解雇されなかったり、処罰さえされなかったことに非常に驚きました。 少なくともロシアでは、多くの指導者にとって、このような行動は奇妙に思えます。 彼らは常に有罪を探し、彼を罰しますが、問題の原因を探して（fakap-私は記事で使用することを禁じられていました）、それらを排除する方が論理的です。 適切な事例は、データベース削除の専門家とgitlabの話です。 犯人を解任すると、貴重な経験をしたばかりのスペシャリストを失い、それを行う方法は不要であり、スタッフの離職率を高めます。 しかし、問題は解決されず、遅かれ早かれ再び発生します。



Coreyが表明した別の重要な考え、そして多くのスピーカーが繰り返しました：「Docker、Docker、Docker」。 現在、あらゆる問題に対する「ユニバーサル」ソリューションがあり、これがDockerです。 それはどこにでも押し込まれ、すべてがそこに移されます。 テクノロジー自体は優れていますが、誇大宣伝はそれをアンチ広告にしました。 すべての穴に押し込まれ始め、「Dockerが必要ですか？」という簡単な質問に最初に答える価値があります。悪い技術はなく、不適切な使用があることを理解することが重要です。 現代のITでは、これは大きな問題です。

第2幕：バルーク・サドグルスキー、レオニード・イゴルニク、当直のヴァシャ

私がk8から選択した2番目のレポート、遅延を引き起こす原因を適切に責める方法、および仕事と義務の組織についてのストーリー。 あまり考えずに、私は勤務しました。 まず、このトピックは当社に近いものです。 第二に、すべての同僚が最初の2つのレポートに行きました。 第三に、技術に関する多くの資料がネット上にあります。



ここに書くことはあまりありません。レポートを見る必要があります。 バルークとイゴルニックは、強力なカリスマ性と優れたスタイルの情報提示を備えています。 勤務中のVasyaの後輩の例では、一晩の事件を処理する例が考慮されました。 すべてが最高の伝統であり、Wordファイルのメールにログを記録し、パニック、必要なサーバーへのアクセスの欠如、不満のクライアント。 クラシック 現実には、これは多くの企業にとって大きな問題であり、それを解決する代わりに、常に有罪を探しています。



ホールは半分空で、多くの人がその過程に残っていましたが、取り上げられたトピックは非常に重要でした。 幸いなことに、啓示はありませんでした;私たちがすでに実装した、または実装段階での提案のほとんど。

第3幕：モニタリング

「SmartMonitoring-Odnoklassnikiのビジネスロジックの監視」、「k8の拡張」、「複数のクラウドFTWの管理」から選択しました。 この選択は最初のレポートで下されたので、私が開発している分野の中で、監視があります。



セルゲイ・シャラポフによって実行されます。 彼の報告は筋金入りかもしれないが、...複雑な印象を残した。



レポートでは、オドノクラスニキでの監視について説明しました。 システムを作成し、グラフの作成方法と、障害の影響を受けたサーバーを強調表示する方法を知っています。 彼女は、以前のデータを分析して、異常を検索する方法を知っています。 すべてがクールですが、技術的な詳細が十分ではありません。 私は助けることができませんが、聴衆からの質問に注意してください：



-なぜあなたはあなたの製品を作り、それを基礎として既製のものと考えなかったのですか？

-できるから。

4番目の行為は何にも記憶されていないため、省略します。

第5幕：インフラストラクチャをクラウドに継続的に提供するためのラウンドテーブル「DevOpsの販売方法、Windowsでの継続的デリバリー。



どこに行くかはすぐに明らかでした。Devopsに関する会議です。つまり、ラウンドテーブルに行くということです。

面白かった。 いくつかの結論：



1. Devopsアプローチは仕事から私たちを解放しません。小さくなりませんが、むしろ逆になります。 しかし、タスクは質的に異なるレベルに到達し、より困難で興味深いものになります。



2.現在、Devopの2つのアプローチへの分離は、devがプロダクションに根ざしているgoogle、netflixアプローチにより明確に追跡されています。 そして他の皆。 2番目のアプローチは、何でもできる1人だけではありません。それは、開発を理解した開発者が開発を理解し、開発を理解すると、従業員の専門能力開発です。 これは、一般的な問題やリクエストに対する密接な相互作用と理解です。



3.現在、ビジネスは急速に発展しているため、唯一の方法はDevOpsです。 しかし、それぞれに独自のパスがあり、常にコンテキストで考慮する必要があります。



Act 6：Kubernetesでの運用アプリケーションのトラブルシューティングとデバッグ、「Success Story」または「Dev + DevOps + Ops」、「One-cloud：OdnoklassnikiのデータセンターレベルのOS」。



選択はトラブルシューティングとデバッグにかかっており、Kubernetesに関する少なくとも1つのレポートを聞く必要がありました。 スピーカー：Baruch Sadogursky、Ray Tsang。

講演はJFrogとgoogleクラウドについてでした。 JavaScriptのリリースとホットフィックスのオンザフライの失敗例が検討されました。 何かを選び出すのは難しいです、ただ興味がありました。

頂点に達したのは「大規模なDevOps：3つの行為におけるギリシャの悲劇」です。

彼らは彼女のバルーク・サドグルスキー、レオニード・イゴルニクを率いていました。 なんて言うことができる、クール。 ギリシャのトーガスとビールの話者から始まりました。 すべてがユーモア、素晴らしい写真、gifで、彼らに特有の方法で発表されました。 彼らは、3人から大企業までのスタートアップの開発について話しました。 会社が開発のあらゆる段階で対処しなければならなかった問題について。



私の意見では、このレポートは論理的な線を引いています。 彼は、開発のあらゆる瞬間に適切なテクノロジーを選択することが重要であることを示しました。 悪い技術がないこと、不適切な使用があること。 DevOpsは、適用できる特定のルールのセットではなく、すべてがクールです。 これは特定のアプローチであるため、作業のアプローチを変更する必要があります。そうすれば、クールになります。

エピローグ

DevOpsカンファレンスは成功しました。 ここに戻りたいです。



PS：休憩中に、多くの参加者は、ハードコアで実際のケースはほとんどないと不満を言いました。 私の意見では、彼らはそこにいるべきではなかった。 この会議はそれについてではありません。 それは、仕事へのアプローチ、製品開発、そしてDevopsは魔法の薬ではなく、正しく使用すれば企業が現代の要件を満たすことができる一連のテクノロジーと方法論に関するものです。 多くの人はこれに対応できていません;彼らはそれが必要かどうかを認識せずに新しい技術を使用しようとします。 あなたが後輩であるか先輩であるかは関係ありません。会議は誰にとっても有益でした。 確かに、後輩でさえ会社の仕事を改善する提案でリーダーシップを発揮することができ、彼に正当な理由があるなら、彼らは彼に耳を傾けます。 そして、あなたも耳を傾けていないなら、そのような会社から逃げて、DevOpsは決してありません、その天井はDockerです:)



PSS：お気づきのように、Dockerはテキストによく見られます。 バルクは、これは切り札だと言っただけで、Dockerが言及すればするほど、記事はクールになります。



UPD：ここでは、主催者の観点から「それがどうだったか」を読むことができます： habrahabr.ru/post/341020



主催者、講演者、関係者全員に感謝します！