チャットでのディスカッションに基づく
最近、DevOps と SRE の定義をめぐって実際の争いが激化しています。
このテーマに関する議論は、私も含めてすでに多くの意味で緊張を強いられているという事実にもかかわらず、私はこのテーマについての私の見解をハブラコミュニティの法廷に持ち込むことにしました。 興味のある方は猫へようこそ。 そしてすべてを新たに始めましょう!
背景
そのため、昔はソフトウェア開発者とサーバー管理者のチームは別々に住んでいたのです。 XNUMX 人目はコードを書き上げることに成功し、XNUMX 人目は最初の人にさまざまな温かい愛情のこもった言葉を使ってサーバーをセットアップし、定期的に開発者のところに来て、包括的な「私のマシンではすべて動作します」という返事を受け取りました。 ビジネスはソフトウェアを待っていて、すべてがアイドル状態で、定期的に壊れ、誰もが緊張していました。 特にこの混乱全体の費用を支払った人。 輝かしいランプの時代。 DevOps がどこから来たのかはすでにご存知でしょう。
DevOps プラクティスの誕生
すると、真面目な人たちがやって来て、「これは業界ではない、そんな風に働くことはできない」と言った。 そして彼らはライフサイクルモデルを導入しました。 たとえば、ここに V モデルがあります。
それで、何が見えるでしょうか？ ビジネスにはコンセプトがあり、アーキテクトがソリューションを設計し、開発者がコードを記述しても、その後失敗します。 誰かが何らかの方法で製品をテストし、誰かが何らかの方法でそれをエンドユーザーに届け、そしてこの奇跡のモデルの出力のどこかに、海辺で約束の天気を待っている孤独なビジネス顧客が座っています。 私たちは、このプロセスを確立できる方法が必要であるという結論に達しました。 そして私たちは、それらを実装する実践方法を作成することにしました。
練習とは何かというテーマに関する叙情的な余談
実践とは、テクノロジーと規律の組み合わせを意味します。 例としては、Terraform コードを使用してインフラストラクチャを記述する実践があります。 規律とはコードでインフラストラクチャを記述する方法であり、それは開発者の頭の中にあり、テクノロジーはテラフォームそのものです。
そして彼らは、それらを DevOps プラクティスと呼ぶことにしました。これは、開発から運用までを意味していたと思います。 私たちは、CI/CD プラクティス、IaC 原則に基づくプラクティスなど、さまざまな賢いものを考え出しました。それらは何千ものものでした。 そして開発者がコードを書き、DevOps エンジニアがコードの形式でシステムの記述を動作するシステムに変換します (はい、残念ながら、コードは単なる記述であり、システムの具体化ではありません)。納品は続行されます。等々。 昨日の管理者は、新しいプラクティスを習得し、誇らしげに DevOps エンジニアとして再トレーニングを受け、そこからすべてが始まりました。 そして夕方があり、朝がありました...申し訳ありませんが、そこからではありません。
またまたすべてがうまくいかない、神に感謝します
すべてが落ち着き、さまざまな狡猾な「方法論者」が DevOps の実践に関する分厚い本を書き始めるとすぐに、悪名高い DevOps エンジニアが誰であるか、DevOps が生産文化であるかについての論争が静かに燃え上がり、再び不満が生じました。 ソフトウェアの配信はまったく簡単ではないタスクであることが突然判明しました。 各開発インフラストラクチャには独自のスタックがあり、どこかでそれを組み立てる必要があり、どこかで環境をデプロイする必要があり、ここでは Tomcat が必要で、ここではそれを起動するための狡猾で複雑な方法が必要です。一般に、頭がドキドキします。 そして、奇妙なことに、問題は主にプロセスの組織にあることが判明しました。この配信機能がボトルネックのように、プロセスをブロックし始めました。 さらに、誰もオペレーションをキャンセルしませんでした。 V モデルには表示されていませんが、右側にはライフ サイクル全体が表示されています。 そのため、インフラの維持や監視、インシデントの解決、さらには配送などの対応も何らかの形で行う必要があります。 それらの。 開発と運用の両方に片足を突っ込んでいましたが、突然、それが開発と運用になったことが判明しました。 そして、マイクロサービスに対する一般的な誇大宣伝がありました。 そして、それらに伴い、ローカル マシンからの開発はクラウドに移行し始めました。何かをローカルでデバッグしようとすると、数十、数百のマイクロサービスがある場合、継続的な配信が生き残る手段になります。 「小規模で控えめな会社」にとっては問題ありませんでしたが、それでもどうでしょうか？ Googleについてはどうですか？
Google による SRE
Google がやって来て、最大のサボテンを食べて、これは必要ない、信頼性が必要だと判断しました。 そして信頼性も管理する必要があります。 そして、信頼性を管理する専門家が必要だと判断しました。 私は彼らを SR エンジニアと呼んで、「これで終わりです。いつものようにしっかりやってください」と言いました。 ここが SLI、ここが SLO、ここがモニタリングです。 そして彼は作戦にも首を突っ込んだ。 そして彼は自分のことを「信頼できる DevOps」SRE と呼びました。 すべてがうまくいっているように見えますが、Google ができる汚いハックが XNUMX つあります。SR エンジニアのポジションには、資格のある開発者で、少しの下調べをして、実際に稼働しているシステムの機能を理解している人を雇うことです。 さらに、Google自体もそのような人材を雇用することに問題を抱えています - 主にGoogle自体と競合するため - ビジネスロジックを誰かに説明する必要があるためです。 デリバリーはリリースエンジニアに割り当てられ、SR - エンジニアは信頼性を管理します（もちろん、直接ではありませんが、インフラストラクチャに影響を与え、アーキテクチャを変更し、変更と指標を追跡し、インシデントに対処します）。 いいですね、できますよ 。 しかし、あなたが Google ではなくても、信頼性が何らかの形で懸念されている場合はどうすればよいでしょうか?
DevOps アイデアの開発
ちょうどそのとき、lxc から発展した Docker が登場し、その後 Docker Swarm や Kubernetes などのさまざまなオーケストレーション システムが登場し、DevOps エンジニアは息を呑みました。プラクティスの統合により配信が簡素化されました。 これにより、開発者に配信をアウトソーシングすることもできるほど簡素化されました (deployment.yaml とは何ですか)。 コンテナ化によって問題は解決されます。 そして、CI/CD システムの成熟度は、すでに XNUMX つのファイルを作成すればすぐに使えるレベルに達しており、開発者自身がそれを処理できるようになります。 そして、私たちは独自の SRE を作成する方法について、... または少なくとも誰かと話し始めます。
SRE は Google に掲載されていません
さて、分かった、配達は完了しました。息を吐き出して、管理者がプロセッサーの負荷を監視し、システムを調整し、静かにマグカップから理解できないものを静かに飲んでいた古き良き時代に戻ることができるようです...やめてください。 これが私たちがすべてを始めた理由ではありません（それは残念です！）。 Google のアプローチでは、優れたプラクティスを簡単に採用できることが突然判明しました。重要なのはプロセッサの負荷ではなく、ディスクを交換する頻度やクラウドのコストを最適化することではありません。しかし、ビジネス指標も同様に悪名高いのです。 SLx。 そして、インフラストラクチャ管理を彼らから外す人は誰もおらず、彼らはインシデントを解決し、定期的に勤務し、通常はビジネス プロセスを常に把握する必要があります。 そして皆さん、少しずつ良いレベルでプログラミングを始めてください。Google はすでにあなたを待っています。
要約する。 突然ですが、あなたはすでに読むのに飽きていて、記事のコメントで著者に唾を吐き、手紙を書くのが待ちきれません。 デリバリー実践としての DevOps はこれまでも、そしてこれからもそうでしょう。 そしてそれはどこにも進みません。 一連の運用プラクティスとしての SRE は、まさにこの実現を成功させます。
出所： habr.com