DevOps:アラートで分裂を橋渡しする

とにかくDevOpsとは一体何ですか?

DevOpsという用語はよく使われます。 他の優れた流行語と同様に、特定の概念を説明するために業界のトレンドセッターによって造られたフレーズとして始まりました。 時間の経過とともに、DevOpsはあいまいな構造に変化し、現在ではほとんどのテクノロジー会議に参加することでDevOpsのセマンティックサティエーション*のリスクがあります。 一歩下がって、「DevOps」で説明されている元の概念を調べると、次のようなものが得られます。

DevOpsは、設計から開発プロセス、生産サポートまで、サービスライフサイクル全体に一緒に参加する運用エンジニアと開発エンジニアの実践です。 DevOpsは、運用スタッフが開発者と同じ手法の多くをシステム作業に利用していることも特徴です。」[出典: https://theagileadmin.com/what-is-devops/]

または、さらに単純化するには、次のようにします。

「DevOps =開発+運用」

目を転がしたり、「がらくたはありません。 続けてください。」 日曜日までずっとこの流行語を聞いている理由は、この単純な概念にはいくつかの非常に強力な利点があるからです。 物理インフラストラクチャの知識と内部リソースランドスケープ(別名Ops知識)により、開発者はよりシンプル、高速、またはよりエレガントな(XNUMXつ選択しますか?)ソリューションを見つけることができます。 逆に、運用チームは、インフラストラクチャ管理の自動化の一環として、開発者の帽子をかぶって時間の大部分を費やしています。

##この記事はLogicMonitorに関するものではなかったのですか?

はい、ご想像のとおり、この記事にはLogicMonitor固有のコンテキストがいくらか含まれる予定でした。 LogicMonitorのTechOpsチーム(以前はOpsDevと呼ばれていました)のメンバーとして、私は常に深刻な状況でDevOpsについて議論するのに苦労していました。 真剣に、私は上司が「DevOps」に非常に反対していたので、「OpsDev」と呼ばれるチームの一員でした。 私たちが取り組んでいるプロジェクトのスピードと複雑さ、チームの成長などを考えると、OpsチームとDevチームが常に同期しているとは限らないことは驚くべきことではありません。 私たちはプロジェクトに協力し、コードの記述、テスト、およびデプロイのための多くの同様のツールとプラクティスを共有していますが、それは常にバレーボール(または中国を拠点とする開発者と協力している場合はバドミントン)をプレイするようなものです。 ビルドツールや実装したCIソリューションを改善するためにいくつのステップを踏んだとしても、その分離感は常に私を悩ませました。 「これは、DevOpsが想定している方法ではありません。」

最終的に分裂を橋渡ししたのは、私が期待した最後のことでした。 アラート。

## DevOpsドラムサークル

数か月前、私たちは開発と運用の両方の責任の大幅な変更を提案しました。 アプリケーションのライフサイクル全体を通じて開発者の所有権を増やし、インフラストラクチャとアプリケーションの両方の問題に対する応答時間を改善したいと考えていました。

歴史的に、リリースがQAを通過し、適切にパッケージ化されると、それはOpsの唯一の所有物になりました。 オペレーションは、この新しいコードのリリースと、リリース後に検出された問題の処理を担当していました。 この方法には素晴らしい点とそうでない点がありました。 として エンタープライズモニタリング 会社では、新しくリリースされたコンポーネントの要件のXNUMXつは、Opsがパフォーマンスの問題を認識できるようにするための包括的なデータソーススイートでした。 ただし、最初の展開後、これらのデータソースの継続的な調整は、構成の変更がパフォーマンスにどのように影響するかをほとんど知らない人の手に委ねられていました。

リリースプロセスの変革を引き起こしたのは、これらのデータソースでした。

開発者は、運用よりもはるかに優れた方法で開発するアプリケーションを知っています。 開発者は、アプリケーションが構成の変更にどのように応答するかを最もよく知っています。 開発者がページの受信を開始すると、問題が発生したときにアラートを送信しながら、これらのデータソースができるだけ静かになるように調整されるようにするインセンティブが追加されます。 これは、インフラストラクチャとアプリケーションの両方のパフォーマンスの問題に関するアラートが最も有能なチームにルーティングされ、解決時間が短縮されることを意味します。 オペレーションをリリースのよりサポート的な役割に移行すると、オペレーションは、開発の鍵を提供する前に、メンテナンスアクションの自動化を大幅に強化する必要があります。 両方のチームがリリースの成功に向けて準備を整えることで、LogicMonitorがソフトウェア開発ライフサイクルにさらに組み込まれることになります。

##結論

今、これはDevOpsのように感じ始めています。 しかし、満足のいくユニコーンに乗って日没に向かう前に、これはDevOpsの道の終わりではありません。 私たちの開発者のほとんどはデータセンターに足を踏み入れたことがなく、私は間違いなくグーグルなしでJavaswitchステートメントを書くことができませんでした。 DevOpsは目的地ではなく、旅です。

*意味飽和(意味飽和)は、繰り返しによって単語やフレーズが一時的に聞き手にとって意味を失い、聞き手がそのスピーチを繰り返し意味のない音として知覚する心理的現象です。 [ソース: https://en.wikipedia.org/wiki/Semantic_satiation]