「双方からのニーズ」：DevOopsプログラム委員会およびDevOpsに関する委員会

DevOpsの概念はすでに最初の日からはほど遠いものですが、それについての議論は「何がすべてなのか」という疑問から始まって、まだ止まりません。 「DevOps-conference」というフレーズも疑問を提起します。たとえば、「dev」と「ops」がここで収束する場合、イベントは開発または管理のバックグラウンドを持つ視聴者を対象としていますか？



このすべてを直接知っている人々の輪があります。DevOopsカンファレンスのプログラム委員会です。この委員会は、この秋にサンクトペテルブルクで初めて開催されます。 イベントのレポートがどうなるかは彼ら次第であるため、DevOpsとカンファレンス自体について質問することにしました。 会話には以下が参加しました：

• バルーク・サドグルスキー （JFrog）
• オレグ・アナスタシエフ （クラスメート）
• アレクセイ・ハコビアン （Dell EMC）
• キリル・トルカチョフ （アルファ研究所）
• アレクサンダー・タラソフ （クラスメート）

そして、議論の間に、あなた方全員に自発的に質問が生じました-このテキストを読むとき、あなたは会議プログラムに個人的に影響を与えることもできます！



JUG.ru：「DevOps」の概念に関連して、論争が見られます。 あなたはそのような問題に連帯を持っていますか、または内部議論がありますか？



Baruch Sadogursky：私の意見では、DevOpsとは何ですか 、誰もが長い間決心しています。



















アレクサンダー・タラソフ：そして、私の意見では、彼らはまだ少し異なって認識しています。 私たちは皆異なる背景を持ち、私たちはすべて異なるものを見ています。 他の言葉と同様に、これはかなり大きな一般化です。 もちろん、人々は共通の理解を持っていますが、詳細は時々大きく異なり、このアイデアを実際の風景に実装する方法は一般に動物園です。









バルーク： 「大丈夫、どうやってやる」と言い始めたら、すべてが違うということに同意します。 しかし、私は、「あなたがそれを構築し、あなたがそれを所有する」などの一般的な考え方の理解があるように思えます。 そして、それを正確に実装する方法はそれほど重要ではありません。



Alexander：多くの場合、DevOpsは狭い意味で理解されます。開発者が開発者であり、運用がシステム管理者である（そして一般的にはメンテナンスではなく、異なる場合があります）。 しかし、私にとってこれはより広い概念です。継続的デリバリーと他の同様のものが離陸するためには、原則として、チーム全体の参加が必要です。 アナリスト、テスターがいます。展開プロセス自体があり、その後、監視などの形でサポートされます。 「DevOps」という言葉にはQAに関するものは何もありませんが、Wikipediaを開いただけでも、ダイアグラム上に3つの円がすぐに表示されます。そのうちの1つはQAです。







JUG.ru：さまざまな側面がdevopaで収束します-主な活動は何ですか？ 開発または管理からの人々から？



バルーク：ほとんどのdevopsnikiは行政から来ています。 大まかに言えば、devopaでの私たちの仕事は何ですか？ 開発者は、システム管理者に書かれたものを投げるのではなく、すべてを本番環境にドラッグできるようにしたいと思います。それが落ちたら、これが彼らの問題です。



これは、彼らがこの後半を学ばなければならないことを意味します。大まかに言えば、彼らは新しいシステム管理者にならなければなりません。 まったく異なるスキルセット、まったく異なるツールセットなどがあります。 誰が彼らを教え、誰が必要なアプリケーションをすべて書くことができ、誰がオフィス内に自動化を構築できますか？ 以前は同じ管理者でしたが、現在はdevopsエンジニアと呼ばれることもあります。 つまり、管理側から来た人はdevopsイネーブラーになり、すべてとツールとプロセスを構成し、文化を再訓練し、歩き回り、なぜこれを行う必要があるのか​​を教えます-これらは元管理者です。 そして、元プログラマーは、大まかに言って、このdevopsを実現するためにこれをすべて使用します。



オレグ・アナスタシエフ：しかし、私は基本的にバルークに同意しません、陰謀があるに違いありません！ 私はそれはむしろ反対だと言うでしょう：この動きはプログラマーから来ています。 管理者は、この用語が出現する前に、伝統的に何らかの種類の手動手順を実行していたため、独自のプロセス、指示があり、手動またはハーフスクリプトで解決していました。 プログラマーは管理者を介してマシン上でコマンドを実行することにうんざりしているため、携帯電話が非常に破損しています。管理者が製品に関する能力の限界に達すると、プログラマーに尋ね始めます。 プログラマー自身は何をすべきかを知らず、命令を開始します。まあ、このディレクトリに何があるのか​​、何の日付、しかし何が見えるのか見てください...



30回に1度、Skypeコンソールを介したこのようなコマンドの実行は機能に支障をきたしますが、プログラマーが本番システムをより詳細に制御したいのは当然です。 そして、プログラマーとして、私たちはあらゆる種類のプログラムを書くのが非常に得意であり、私たちの生活を楽にするこれらのプログラムをいくつか書いてから、それらを書いて、何らかの形でそれをモデル化し、アーキテクチャを構築し、再びねじ込み、ここでそれをひねりました-そして、devopsが判明しました そして、管理者にすべてを実行、インストール、構成する方法を教え、彼らもこれらのプログラムから利益を得るようになりました。



バルーク：オレグ、私たちはどちらも正しいと思いますし、両側にニーズが生じると思いますが、私たちが話している人気のあるツールは（CIサーバーを除き、単に開発者の前に作成されたため）あらゆる種類のインフラストラクチャとして-a-Service、Chef、Ansible、同じDockerなど-開発者ではなく管理者が作成します。 つまり、これらはツールです。



オレグ：さて、ここオドノクラスニキでは、どういうわけか逆です。 リストされたツールについて、私は性格について議論することは何もありません、私はそれらをあまりよく知りませんが、それでも管理者だけがそれを必要とした場合、誰も何もしません。 ここで重要なのは、両方のキャンプに独自の利点がある場合に相乗効果が得られることです。



バルク：私はこれを言います：ビジネスはそれを必要とします。



Alexey Hakobyan：これを追加したいです。 私の意見では、近年、製品を置き換える多くのサービスが存在することが重要です。 従来、ソフトウェアビジネスの大部分はパッケージ化された製品であり、チームが作成してから、無制限の数の顧客に配布したため、どこかに展開する必要がありました。 したがって、管理者は主に顧客側にいたため、指示が必要でした。 そして今、業界は公共サービス（および内部サービス）に向けて非常に強力に進化しています。 したがって、多くの場合、サポートが必要なクラウドに広がる唯一の展開を通じてユーザーがやり取りするサービスがあるという事実に直面しています。 そして、これは、私の意見では、devopsのイデオロギー全体に非常に大きな推進力を与えました。コードではなく、実用的なサービスの共有です。



JUG.ru：会議に関連してこれはすべてどういう意味ですか？ DevOopsの主な目的は、開発または管理のバックグラウンドを持つ人々ですか？



バルーク：従来、ほとんどすべての西部のDevOps会議（DevOps Days、DevOps Enterprise Summitなど）は、管理者からのDevOpsに非常に焦点を当てていました。 そこで彼らは彼らのツールの根性について、そして大まかに言って「プログラマーに正しいdevopを行う方法を訓練する方法」について議論します。



そして、私たちの会議でプログラマもいるというのは興味深いと思います。 すべてのJUG.ruグループ会議の主な対象者は、一般的にプログラマティックです。 「管理者でなくてもdevopsのカンファレンスに参加する」というアプローチは一般的に常に正しいですが、私たちにとっては特に正しくて興味深いものです。まず、それは私たちにとって自然な聴衆であるためです。従来のdevops会議用。



アレクサンダー：私は自分自身を「開発者と管理者」に制限することさえしません。 原則として、自動化の問題、開発および実装プロセスの組織を改善してクライアントへの価値の提供を促進すること、現在これに使用できるツール、および彼らがどのように彼の問題を解決することに関心を持っている大勢の人々にとって興味深いはずです。 筋金入りの部分、「10,000のサービスを監視するスーパーモニタリングの実行方法」について聞いてみたいと思います。 他の人は、組織の問題を解決することにもっと興味があります。 わが国では技術報告書が主流ですが、多くの場合、この分野の問題は技術的および組織的です。



JUG.ru：すでに主要なトピックのリストから、レポートが実際に非常に技術的なものになることは明らかです。特定のツールがどこでもすぐに示されます。 「継続的な配信」だけでなく、「Jenkins、TeamCity、Bamboo」のリストもあります。 より一般的なパフォーマンスは、特定の製品に関連付けられていませんか？



バルーク： 2つのコンポーネントがあるように思えます。 まず、ある種の一般的な継続的デリバリーについて話します-それらは抽象的であり、何もありません。 それは非常に表面的なものか、特定のアプリケーションがまったくないもののいずれかです。 そして、JUG.ruグループ会議で通常行われるように、レポートを選択する際の2つの基本的な要因は、第一に有用性であり、第二にハードコアです。 そして、いくつかの一般的なレポートはあまり有用ではなく、あまり技術的ではなく、特にハードコアではありません。



第二に、私の意見では、まだ決定していないという疑問があります。 JUG.ruのバックグラウンドのため、私たちは特定のテクノロジーとツールによって研ぎ澄まされています：ソフトスキルとアジャイルではなく、ガッツ、ハードコア、テクノロジー。



しかし、devops専用のアプリケーションでは、これが問題になります。なぜなら、実際に彼と関係を持っている人なら誰でもdevopsのツールや技術が最初のものではないと言うからです。 はい、私たちはそれについて話すのが大好きです、そしてそれについて話すことは私たちにとって便利です：私たちはすべて技術者、プログラマーです、私たちはすぐにそれに引き付けられます、設定を見てみましょう。



しかし、問題は人々の行動にあります。 プログラマーと管理者の2つのキャンプから1つのプロセスが得られるように変更する方法は？ これまでのところ、誰も私たちに影響を与えていません。第一に、原則として、それがどのように影響するかはあまり明確ではありません。第二に、JUG.ru基準によるこのようなレポートは、軽くてソフトなスキルでブランド化されます



開会の基調講演がまさにそれであることを願っています。 少なくとも、レオニード・イゴルニックとの私の最後の基調講演は、テクノロジーについて100％ではありません。 しかし、疑問は残っています。



Kirill Tolkachev：他のカンファレンスでは、BizOpsと呼ばれるレポートがあります。 従来、大企業のトップとして、私は会社にdevopsを導入することの利点について、成功の公式を説明する図で語っています。 聞いて、これが欲しい？



バルク：レポートに大きく依存しています。 「ピープル-プロセス-ツール」の三角形の堅実なツールがあることをうめきに間に合います。このようなレポートは、単なるおしゃべりではない場合、人々とプロセスを非常にクールなものにします。最初は反対だった...」、つまり、計算、数字、プロセス、何が変わったのか、誰が解雇され、誰が雇われたのか。 それはすべて、良いレポートだけでなく、素晴らしい基調講演になると思われます。



アレクサンダー：これは、側面から、上層階からの興味深い眺めです。 非常に多くの場合、普通の役職で働く人々は、どんな種類の問題があるのか​​、また大企業で一見すると一見非論理的と思われる決定を下す理由を理解していないだけです。 これについて話すのがいいことだとすれば、非常に興味深い結果になる可能性があります。



バルーク：それとも、何らかのペアレポートを作成しますか？ 大まかに言えば、ビジネスのかなり高いレベルの人、開発側の人。 そして、ここでこの議論を示すために、一方で、開発者はどのようにボスを説得することができ、他方で、ボスは開発者とどのくらい困難ですか？ または、Cレベルの人を何人か集めて、パネルディスカッションを行いますか？



アレクセイ：私たちの議論がそのような議論に興味を持つかどうかのトピックに関する調査を行うことはできますか？



JUG.ru：はい、質問ではありません。 このテーマについて意見をお持ちの読者- リンクをたどってオプションの1つを選んでください。会議の改善にご協力ください。



「ツールに添付されたレポート」に戻る：スピーカーは主にこれらのツールを積極的に使用する人ですか、それとも作成する人ですか？



バルク：さまざまなケースがあります。 HashiCorpのスピーカーがいます。HashiCorpは、私たち全員が愛する非常に多くの非常に良いdevobs製品を生産しています。 Google Cloud Platformの開発者の1人がいることを願っています-もちろん、彼らも非常に好きです。 JFrog Artifactoryの開発に携わった人もいます。信じられないかもしれません！



JUG.ru：あなた自身がJFrogで働いているという事実と、他のスピーカーが彼ら自身のプロジェクトを発表するという事実のために、「しっかりした恐ろしいマーケティングをして、役に立たないように」と言いたい人がいるでしょう。 何かお答えしますか？



バルーク：言うまでもなく、私たちはレポートを可能な限り深く興味深いものにするよう努めており、何らかの販促製品の売り込みではありません。 レポートは技術的な構成要素に応じて選択され、製品の売り込みにならないように実行とリハーサルを行います。 他のJUG.ruグループ会議に参加していた人は、すでにこのことを確信できました。



しかし、特定の人々は、あなたが会社を代表し、その製品の名前を報告書で言及すれば、それについて何を言っても問題ではなく、悪の代表であり、トマトを投げなければならないと信じています。 すみません、ペント！



私はこれを言います：あなたがプロジェクトを使用したか、それを使用する計画があるなら、DevOopsに関するこのプロジェクトのレポートはあなたにとって興味深く、役に立つでしょう。 使用せず、使用すると思わない場合は、単にこのレポートにアクセスしないでください。 いくつかのトラックがあり、いつでも選択できます。 しかし、もし人がTerraformやPackerを使用しているなら、彼はHashiCorpで働いている人の報告に大いに喜んで行くことは間違いありません。



そして、ロシアでの会議のおかげで、私たちは宣伝したい人々の猛攻撃から多かれ少なかれ保護されています。 ロシアでは、devopsの製品開発はまだ十分に開発されていません。 実質的に「自分の製品についてお話ししたい」というサービスを提供する人はいません。 この会議で議論されるほとんどの製品（CIサーバー、開発ツール、仮想化）は海外で開発されています。 したがって、この会社の講演者は、私たち自身が彼を招待した場合にのみ連絡を取ることができます。 そして、私たちが彼を招待するとき、私たちは当然、これが製品の売り込みにならないようにするために必要なすべての措置を取ります。



アレクサンダー：人がテクノロジーにあまりdrれていないように見える場合もありますが、報告書はすべてがとても素晴らしく、すぐにそれを取り、すぐに仕事をする、落とし穴がないという感覚を残しています...原則として、そのような報告書は「101 」、概要レポートまたはエントリレベルのレポートです。 これらは、この技術について何も知らないか、ほとんど知らない人々に役立ちます。



そして、すでに自分自身で何かを研究し、本番環境で使用している人は、内部実装の詳細、特に落とし穴に興味を持っています。 したがって、スピーカーが自分の製品、ライブラリ、技術をよく知っているだけでなく、肯定的な側面について話すだけでなく、ユーザーの問題を知っていて、あらゆるエンジニアリングソリューションに存在するさまざまなトレードオフについて話すことができるのは素晴らしいことです。



JUG.ru：他のJUG.ruカンファレンス、たとえばJokerでは、すでに「ヨーロッパに近い」レポートがありました。 別の会議が登場した今、何が起こりますか？彼らはすべてそこに移動していますか、それともジョーカーでまだ見ることができますか？



バルーク：これは非常に良い質問です。両方の会議のプログラム委員会に参加しているので、私は両側から見ています。



一方で、はい、DevOopsのすべてのdevobskihレポートを移動したいという大きな要望があります。 しかし、一方で、そのトピックが興味深い場合、ジョーカーだけに来て、DevOopsに行く予定のない人には、これらのトピックをまったく使わないでほしくありません。 したがって、devopsおよびJavaに関連するレポートをJokerに残し、Javaに関連しないレポートをDevOopsに提供しようとしています。



オレグ： 2つの会議のトピックが同じであることが判明した場合でも、DevOopsではプロセスと一部の管理と運用の部分について、Jokerではハードコアとプログラミングについてより多くのトピックを追加します。 トピックは同じですが、異なる角度から検討されます。



JUG.ru：答えてくれてありがとう。 他に何か追加しますか？



Alexey： DevOopsがフィードバックを収集した後、次の会議で同じ質問にすべて答えることができます。 実際には、DevOopsに実際に来た人にとって何が本当に十分で、何が十分ではなかったかを理解します。



JUG.ru：つまり、最初の会議に参加する人によって異なりますが、2番目の会議はどうなりますか？ 良いインセンティブ。

---

DevOops は 10月20日にサンクトペテルブルクで初めて開催され、チケットはすでに販売されています（そして時間とともにより高価になります！）。 主なトピック：



-コンテナ、オーケストレーション（Docker、Kubernetes、クラスターなど）。

-仮想化、クラウドテクノロジー（AWS、Azure、Herokuなど）。

-アプリケーション（Prometeus、OkMeter、DataDog、BPF、Dynatrace、XRebel、Glimpse、Zipkin、OpenTraceなど）の監視と監査。

-継続的デリバリー（Jenkins、TeamCity、Bamboo）。

-構成管理（人形、シェフ、アンシブル）。

-セキュリティ（Vaultなど）

-DevOpsを実装する大規模プロジェクトの例に関する報告：成功と失敗。