DevOps アプローチのファンのためのカンファレンス

もちろん、私たちが話しているのは、 DevOpsConf。 詳細を説明しない場合は、30 月 1 日と XNUMX 月 XNUMX 日に、開発、テスト、運用のプロセスを統合するためのカンファレンスを開催します。詳細を説明する場合は、cat の下にお願いします。

DevOps アプローチ内では、プロジェクトの技術開発のすべての部分が絡み合い、並行して発生し、相互に影響を及ぼします。 ここで特に重要なのは、リアルタイムで変更、シミュレーション、テストできる自動化された開発プロセスの作成です。 これにより、市場の変化に即座に対応できます。

カンファレンスでは、このアプローチが製品開発にどのような影響を与えるかを示したいと考えています。 クライアントに対するシステムの信頼性と適応性がどのように確保されるか。 DevOps によって、企業の業務プロセスの組織化に対する構造とアプローチがどのように変化するか。

舞台裏で

私たちにとって、DevOps アプローチの枠組みの中でさまざまな企業が何を行っているかを知るだけでなく、なぜこうしたことが行われるのかを理解することも重要です。 したがって、専門家だけでなく、DevOps の議論をさまざまな立場から見る専門家もプログラム委員会に参加するよう招待しました。

• 上級エンジニア。
• 開発者;
• チームリーダー;
• CTO。

一方で、このことは、報告の要求について議論する際に困難や対立を引き起こします。 エンジニアが重大事故の分析に興味がある場合、開発者はクラウドやインフラストラクチャで動作するソフトウェアの作成方法を理解することがより重要です。 しかし、同意することで、エンジニアから CTO まで、あらゆる人にとって価値があり、興味深いプログラムを作成することができます。

私たちのカンファレンスの目的は、最も誇大宣伝されたレポートを選択することだけではなく、DevOps アプローチが実際にどのように機能するか、新しいプロセスに移行する際にどのような影響を受ける可能性があるかなど、全体像を提示することです。 同時に、ビジネス上の問題から特定のテクノロジーに至るまで、コンテンツ部分を構築します。

カンファレンスのセクションは以前と同じです。 前回.

• インフラストラクチャプラットフォーム。
• コードとしてのインフラストラクチャ。
• 継続的な配信。
• フィードバック。
• DevOps のアーキテクチャ、CTO のための DevOps。
• SRE の実践。
• トレーニングとナレッジマネジメント。
• セキュリティ、DevSecOps。
• DevOps の変革。

論文募集: どのような種類のレポートを求めていますか

私たちは条件付きでカンファレンスの潜在的な聴衆を、エンジニア、開発者、セキュリティ専門家、チームリーダー、CTOのXNUMXつのグループに分けました。 各グループにはカンファレンスに参加する独自の動機があります。 そして、これらの立場から DevOps を見ると、トピックをどのように焦点を当てるべきか、どこに重点を置くべきかがわかります。

エンジニアにとっては、 インフラストラクチャ プラットフォームを作成している人にとって、既存のトレンドを理解し、どのテクノロジーが現在最も進んでいるのかを理解することが重要です。 彼らは、これらのテクノロジーを使用した実際の経験について学び、意見を交換することに興味を持つでしょう。 エンジニアは、重大な事故を分析したレポートを喜んで聞くでしょう。そして、私たちはそのようなレポートを選択し、洗練させようとします。

開発者向け 次のような概念を理解することが重要です クラウドネイティブアプリケーション。 つまり、クラウドやさまざまなインフラストラクチャで動作するようにソフトウェアを開発する方法です。 開発者はソフトウェアから常にフィードバックを受け取る必要があります。 ここでは、企業がこのプロセスをどのように構築するか、ソフトウェアのパフォーマンスを監視する方法、配信プロセス全体がどのように機能するかについての事例を聞きたいと考えています。

サイバーセキュリティのスペシャリスト 社内の開発および変更プロセスが滞らないように、セキュリティ プロセスを設定する方法を理解することが重要です。 DevOps がそのようなスペシャリストに課す要件に関するトピックも興味深いでしょう。

チームリーダーが知りたいこと、他の企業における継続的デリバリープロセスの仕組み。 企業はこれを達成するためにどのような道をたどったのか、DevOps 内で開発と品質保証のプロセスをどのように構築したのか。 チームリーダーもクラウドネイティブに興味を持っています。 また、チーム内および開発チームとエンジニアリング チームの間の相互作用に関する質問もあります。

のために CTO 最も重要なことは、これらすべてのプロセスを接続し、ビジネス ニーズに合わせて調整する方法を見つけ出すことです。 彼は、アプリケーションがビジネスとクライアントの両方にとって信頼できるものであることを確認します。 そしてここでは、どのテクノロジーがどのビジネスタスクに機能するのか、プロセス全体を構築する方法などを理解する必要があります。 CTO は予算編成の責任も負います。 たとえば、スペシャリストが DevOps で働けるようにするために、スペシャリストの再トレーニングにどれだけの費用がかかるかを理解する必要があります。

これらの件について何か言いたいことがあれば、黙っていないでください。 レポートを提出する。 論文募集の締め切りは20月XNUMX日です。 登録が早ければ早いほど、レポートを完成させてプレゼンテーションの準備に費やす時間が長くなります。 だから、遅らせないでください。

まあ、公に話す必要がない場合は、 チケットを買う 30 月 1 日と XNUMX 月 XNUMX 日には同僚とコミュニケーションをとるために来てください。 面白くて感動的なものになることをお約束します。

DevOps をどう見るか

DevOps が何を意味するのかを正確に理解するには、私のレポートを読む (または再読する) ことをお勧めします。DevOpsとは」 市場の波の中を歩きながら、小規模な新興企業から多国籍企業まで、さまざまな規模の企業で DevOps の考え方がどのように変化しているかを観察しました。 レポートは一連の質問に基づいて作成されており、質問に答えることで、あなたの会社が DevOps に向かって進んでいるのか、それともどこかに問題があるのか​​を理解することができます。

DevOps は複雑なシステムであり、以下を含める必要があります。

• デジタル製品。
• このデジタル製品を開発するビジネス モジュール。
• コードを書く製品チーム。
• 継続的デリバリーの実践。
• サービスとしてのプラットフォーム。
• サービスとしてのインフラストラクチャ。
• コードとしてのインフラストラクチャ。
• 信頼性を維持するための個別のプラクティスが DevOps に組み込まれています。
• すべてを説明するフィードバックの実践。

レポートの最後には、社内の DevOps システムの概要を示す図があります。 これにより、社内のどのプロセスがすでに合理化されており、どのプロセスがまだ構築されていないのかを確認できます。

レポートの動画をご覧いただけます ここで.

そして今、ボーナスがあります: RIT++ 2019 のいくつかのビデオでは、DevOps 変革の最も一般的な問題について触れています。

製品としての企業インフラ

Artyom Naumenko は Skyeng の DevOps チームを率い、会社のインフラストラクチャの開発を担当しています。 同氏は、インフラストラクチャが SkyEng のビジネス プロセスにどのような影響を与えるか、つまりインフラストラクチャの ROI を計算する方法、計算にどのような指標を選択する必要があるか、およびそれらを改善するためにどのように取り組むかについて説明しました。

マイクロサービスへの道

Nixys 社は、多忙な Web プロジェクトと分散システムのサポートを提供します。 同社のテクニカル ディレクターである Boris Ershov 氏は、5 年前 (またはそれ以上) 前に開発が始まったソフトウェア製品を最新のプラットフォームに変換する方法について語りました。

原則として、このようなプロジェクトは、現在のエンジニアが知らないインフラストラクチャの非常に暗く古い部分が存在する特別な世界です。 そして、かつて選択されたアーキテクチャと開発のアプローチは時代遅れであり、ビジネスに同じペースの開発と新しいバージョンのリリースを提供することはできません。 その結果、すべての製品リリースは信じられないほどの冒険となり、常に何かが、最も予期せぬ場所で落ちてしまいます。

このようなプロジェクトの管理者は、必然的にすべての技術プロセスを変革する必要に直面します。 ボリス氏は報告書の中で次のように述べた。

• プロジェクトに適切なアーキテクチャを選択し、インフラストラクチャを整理する方法。
• どのツールを使用するか、変革への過程でどのような落とし穴に遭遇するか。
• 次はどうする。

リリースの自動化、または迅速かつスムーズに配信する方法

Alexander Korotkov は、CIAN の CI/CD システムの主要な開発者です。 彼は、品質を向上させ、コードを本番環境に配信する時間を 5 分の XNUMX に短縮することを可能にした自動化ツールについて話しました。 しかし、このような成果は自動化だけでは達成できないため、アレクサンダー氏は開発プロセスの変化にも注意を払いました。

事故はどのように学習に役立ちますか?

Alexey Kirpichnikov は、SKB Kontur で DevOps とインフラストラクチャを 5 年間実装してきました。 1000 年間にわたって、彼の会社ではさまざまな程度の壮大なファカップが約 36 件発生しました。 たとえば、そのうちの 14% は、低品質のリリースを運用環境に展開したことが原因であり、XNUMX% はデータセンターでのハードウェアのメンテナンス作業が原因でした。

同社のエンジニアが数年連続で維持してきたレポート（事後分析）のアーカイブにより、事故に関するこのような正確な情報を入手することが可能になります。 事後分析は、緊急信号に最初に反応し、すべての修復を開始した勤務中のエンジニアによって書かれています。 なぜレポートを書くことでfacapと夜戦するエンジニアを苦しめるのか？ このデータにより、全体像を把握し、インフラストラクチャ開発を正しい方向に進めることができます。

アレクセイ氏は講演の中で、本当に役立つ事後分析の書き方と、そのような報告書を大企業で実践する方法について語った。 誰かが失敗した話が好きなら、パフォーマンスのビデオを見てください。

お客様の DevOps のビジョンが私たちのビジョンと一致しない可能性があることを理解しています。 DevOps の変革をどのように見ているかは興味深いでしょう。 このトピックに関するあなたの経験やビジョンをコメントで共有してください。

すでにプログラムに受け入れられているレポートは何ですか?

今週、プログラム委員会はセキュリティ、インフラストラクチャ、SRE の実践に関する 4 つの報告書を採択しました。

おそらく、DevOps 変革で最も苦痛なトピックは、開発、運用、管理の間にすでに構築されているつながりを情報セキュリティ部門の担当者が破壊しないようにするにはどうすればよいかということです。 情報セキュリティ部門を持たずに経営している企業もある。 この場合、情報セキュリティをどのように確保すればよいでしょうか? それについて 教えてくれる Mona Arkhipova s​​udo.su より。 彼女の報告から次のことがわかります。

• 何を誰から守る必要があるのか​​。
• 日常的なセキュリティ プロセスとは何ですか。
• IT と情報セキュリティのプロセスがどのように交差するか。
• CIS CSC とは何か、およびその実装方法。
• 定期的な情報セキュリティチェックをどのように、どのような指標で実施するか。

次のレポートは、コードとしてのインフラストラクチャの開発に関するものです。 手動ルーチンの量を減らし、プロジェクト全体を混乱に陥らないようにすることは可能ですか? この質問に対して 答えます Ixtensのマキシム・コストリキン。 彼の会社が使っているのは、 テラフォーム AWS インフラストラクチャを操作するためのものです。 このツールは便利ですが、問題は、使用時に巨大なコード ブロックの作成を回避する方法です。 このような遺産の維持費は年々高額になるでしょう。 

マキシムは、自動化と開発の簡素化を目的として、コード配置パターンがどのように機能するかを示します。

もう一つ 報告 からインフラストラクチャについて聞きます プレイキーのウラジミール・リャボフ。 ここではインフラストラクチャ プラットフォームについて説明し、次のことを学びます。

• ストレージスペースが有効に使用されているかどうかを理解する方法。
• 10 TB のストレージのみが使用されている場合に、数百人のユーザーが 20 TB のコンテンツを受信できる方法。
• データを5倍に圧縮してリアルタイムでユーザーに提供する方法。
• 複数のデータセンター間でデータをオンザフライで同期する方法。
• XNUMX つの仮想マシンを連続して使用するときに、ユーザー同士の影響を排除する方法。

この魔法の秘密はテクノロジーです FreeBSD 用の ZFS そしてその新鮮なフォーク Linux上のZFS。 ウラジミールは Playkey からのケースを共有します。

Amixr.IO の Matvey Kukuy 人生の例を用意してあります 伝える、 何が起こったか SRE そして、それが信頼性の高いシステムの構築にどのように役立つかについて説明します。 Amixr.IO はクライアントのインシデントをバックエンド経由で受け渡しており、世界中の数十の勤務チームがすでに 150 万件を処理しています。 マトベイ氏はカンファレンスで、顧客の問題を解決し、失敗を分析することで同社が蓄積した統計と洞察を共有する予定だ。

もう一度言いますが、貪欲にならず、DevOps サムライとしての経験を共有してください。 仕える リクエスト レポートを作成するために、あなたと私は素晴らしいスピーチを準備するのに 2,5 か月半かかります。 聞き手になりたい方は、 申し込む プログラムの最新情報を掲載したニュースレターをチェックし、カンファレンスの日程が近づくとチケットの価格が高くなるため、事前にチケットを予約することを真剣に検討してください。

出所： habr.com