開発者のSREへの道：インフラストラクチャに行く理由とそれから何が生まれるのか

約1年前、.NET開発者からSREに再トレーニングしました。この記事では、経験豊富な開発者のグループがC＃を脇に置き、Linux、Terraform、Packerを学び、NALSDを作成してIaCを構築する方法、会社のインフラストラクチャを管理するために極端なプログラミング手法をどのように適用したか、そしてそれから何がもたらされたかについて説明します。









世界13か国のDodo Pizzaには600を超えるピザ屋があり、ピザ屋のプロセスのほとんどは、私たち自身が作成して管理しているDodo IS情報システムによって管理されています。したがって、システムの信頼性と安定性は生存のために重要です。



現在、社内の情報システムの安定性と信頼性はSRE（サイト信頼性エンジニアリング）チームによってサポートされていますが、常にそうであるとは限りませんでした。

背景：開発者とインフラストラクチャの並列世界

長年、私は典型的なフルスタック開発者（および少しのスクラムマスター）として開発し、優れたコードの記述方法を学び、Extreme Programmingの実践を適用し、私が触れたプロジェクトのWTFの数を熱心に減らしました。しかし、ソフトウェア開発で経験を積むほど、アプリケーションの信頼性の高い監視および追跡システム、高品質のログ、完全な自動テスト、およびサービスの高い信頼性を保証するメカニズムの重要性に気づきました。そして、ますます頻繁に、彼はインフラチームに「垣根を越えて」見始めました。



私のコードが動作する環境を理解すればするほど、驚かされます。ソフトウェアの世界でのすべて、すべての人に対する自動テスト、CI、頻繁なリリース、安全なリファクタリング、およびコードの所有権の共有は、昔から一般的で親しみ深いものです。同時に、「インフラストラクチャ」の世界では、自動テストがなく、セミマニュアルモードで本番システムに変更を加えることは依然として正常であり、ドキュメントは多くの場合、個人の頭だけにあり、コードにはありません。



この文化的および技術的格差は、混乱だけでなく問題も引き起こします。開発、インフラストラクチャ、およびビジネスの交差点においてです。インフラストラクチャの問題の中には、ハードウェアに近接しており、ツールの開発が比較的不十分なため、対処が難しいものがあります。しかし、すべてのAnsibleプレイブックとBashスクリプトを完全なソフトウェア製品として検討し始め、それらに同じ要件を適用すると、残りの部分は無効になる可能性があります。

問題のバミューダトライアングル

しかし、私は遠くから始めます-これらすべてのダンスが必要とされる問題で。

開発者の問題

2年前、私たちはピザ屋の大規模なネットワークが私たち自身のモバイルアプリケーションなしでは生きられないことに気付き、それを書くことにしました。

• クールなチームを編成しました。
• 6か月間、彼らは便利で美しいアプリケーションを作成しました。
• 美味しいプロモーションでグランドローンチをバックアップしました。
• そして、初日に彼らは無事に荷を下しました。

もちろん、最初はたくさんの浅瀬がありましたが、何よりもまず覚えています。開発時に、弱いサーバーが本番環境にデプロイされました。ほとんどがアプリケーションからのリクエストを処理する計算機です。アプリケーションの公表前に、それを増やす必要がありました-私たちはAzureに住んでおり、これはボタンをクリックすることで解決しました。



しかし、誰もこのボタンを押していません。インフラストラクチャチームは、アプリケーションが今日リリースされていることさえ知りませんでした。彼らは、「重要ではない」サービスの生成の監視はアプリケーションチームの責任であると決定しました。そして、バックエンド開発者（これはDodoでの彼の最初のプロジェクトでした）は、インフラストラクチャのメンバーが大企業でこれを行っていると決定しました。



その開発者は私でした。それから私は明白だが重要なルールを思いつきました：

, , , . .

今は難しくありません。近年、プログラマーが悪用の世界を調べて何も壊さないようにするための多数のツールが登場しました：Prometheus、Zipkin、Jaeger、ELKスタック、Kusto。



ただし、多くの開発者は、インフラストラクチャ、DevOps、SREと呼ばれるものに関して深刻な問題を抱えています。その結果、プログラマー



はインフラストラクチャチームに依存します。それは痛み、誤解、時には相互の憎悪を引き起こします。



彼らはシステムを現実から分離して設計し、どこでどのようにコードが実行されるかを考慮していません。たとえば、クラウドでの生活のために開発されているシステムのアーキテクチャと設計は、オンプレミスでホストされているシステムの設計とは異なります。



彼らは、コードに関連するバグや問題の性質を理解していません。これは、問題が負荷、クエリバランシング、ネットワークまたはハードドライブのパフォーマンスに関連している場合に特に顕著です。開発者は常にこの知識を持っているとは限りません。



彼らは、コードの保守に使用される会社の資金やその他のリソースを最適化することはできません。私たちの経験では、インフラストラクチャチームは、問題をお金で満たすだけです。たとえば、運用環境でデータベースサーバーのサイズを増やします。したがって、多くの場合、コードの問題はプログラマにさえ届きません。なんらかの理由で、インフラストラクチャのコストが増加し始めただけです。

インフラ問題

「反対側」にも困難があります。



高品質のコードがなければ、数十のサービスと環境を管理することは困難です。現在、GitHubには450を超えるリポジトリがあります。それらのいくつかは運用サポートを必要としません、いくつかは死んで歴史のために保存されていますが、重要な部分はサポートする必要があるサービスを含んでいます。彼らはどこかにホストする必要があり、監視、ログの収集、均一なCI / CDパイプラインが必要です。



これらすべてを管理するために、最近、Ansibleを積極的に使用しました。Ansibleリポジトリには以下が含まれています：

• 60の役割;
• プレイブック102冊。
• PythonおよびBashでのバインディング。
• Vagrantでの手動テスト。

これはすべて、賢い人によって書かれ、よく書かれました。しかし、インフラストラクチャの他の開発者やプログラマーがこのコードを積極的に使用し始めるとすぐに、プレイブックが壊れ、役割が重複して「苔で覆われて」しまうことがわかりました。



その理由は、このコードがソフトウェア開発の世界で多くの標準的な手法を使用していなかったからです。 CI / CDパイプラインがなく、テストは複雑で低速だったため、誰もが面倒で「時間がない」ため手動で実行できず、さらに新しいテストを作成していました。このようなコードは、2人以上で作業すると破滅します。



コードの知識なしにインシデントに効果的に対応することは困難です。午前3時にPagerDutyにアラートが来たら、何をどのように説明するプログラマーを探す必要があります。たとえば、これらの500のエラーはユーザーに影響を与えますが、他のエラーはセカンダリサービスに関連付けられていますが、エンドカスタマーにはそれが表示されず、朝までそのようなすべてを残すことができます。しかし、朝の3時にプログラマを起こすのは難しいので、サポートするコードがどのように機能するかを理解することをお勧めします。



多くのツールでは、アプリケーションコードに埋め込む必要があります。インフラストラクチャの担当者は、何を監視し、どのようにログに記録し、追跡のために何に注意を払うべきかを知っています。しかし、多くの場合、これらすべてをアプリケーションコードに埋め込むことができません。そして、何をどのように埋め込むかわからない人。



「壊れた電話」。100回目、何をどのように監視するかを説明するのは不愉快です。アプリケーションで再利用するためにプログラマーに渡す共有ライブラリーを書く方が簡単です。ただし、これを行うには、同じ言語で同じスタイルで、アプリケーション開発者が使用するのと同じアプローチでコードを記述できる必要があります。

ビジネス上の問題

ビジネスには、対処する必要のある2つの大きな問題もあります。



信頼性と可用性に関連するシステムの不安定性による直接的な損失。

2018年には、51の重大なインシデントがあり、システムの重大な要素が合計で20時間を超えて機能しませんでした。金銭的には、これは未配達および未配達の注文による直接損失の2500万ルーブルです。そして、従業員、顧客、フランチャイズ加盟店の信頼をどれほど失ったかは計算できません。



現在のインフラストラクチャサポートコスト。同時に、同社は2018年の目標を設定しました：ピッツェリアあたりのインフラストラクチャのコストを3倍に削減することです。しかし、チーム内のプログラマーもDevOpsエンジニアも、この問題の解決に近づくことはできませんでした。これには理由があります。

• , ;
• , operations ( DevOps), ;
• , .

?

これらの問題をすべて解決するにはどうすればよいですか？この解決策は、Googleの「サイト信頼性エンジニアリング」という本で見つけました。それを読んだとき、私たちは理解しました-これが私たちが必要とするものです。



しかし、ニュアンスがあります。これをすべて実装するには何年もかかり、どこかから始めなければなりません。最初に持っていた初期データを検討してください。



インフラストラクチャ全体がほぼすべてMicrosoft Azureに存在します。ヨーロッパ、アメリカ、中国など、さまざまな大陸にまたがる独立した販売クラスターがいくつかあります。生産を繰り返すが孤立した環境に住んでいるロードスタンドと、開発チーム用の数十のDEV環境があります。



私たちがすでに行った優れたSREプラクティスのうち、

• アプリケーションとインフラストラクチャを監視するためのメカニズム（ネタバレ：2018年、私たちはそれらが良かったと思っていましたが、すでにすべてを書き直しています）。
• 24/7 on-call;
• ;
• ;
• CI/CD- ;
• , ;
• SRE .

しかし、最初に解決したかった問題がありました



。インフラストラクチャチームが過負荷でした。現在のオペレーティングシステムのため、グローバルな改善のための十分な時間と労力がありませんでした。たとえば、非常に長い間必要でしたが、Elasticsearchをスタックから取り除くことも、リスクを回避するために別のクラウドプロバイダーからインフラストラクチャを複製することもできませんでした（ここで、マルチクラウドですでに試した人は笑うかもしれません）。



コードのカオス。インフラストラクチャコードは無秩序で、さまざまなリポジトリに散在しており、どこにも文書化されていません。すべては個人の知識に依存し、他には何もありませんでした。これは巨大な知識管理の問題でした。



「プログラマーとインフラストラクチャエンジニアがいます。」かなりよく発達したDevOpsカルチャーがあったという事実にもかかわらず、まだこの分離がありました。異なる言語を話し、異なるツールを使用する、まったく異なる経験を持つ2つのクラスの人々。もちろん、彼らは友達であり、コミュニケーションを取っていますが、完全に異なる経験のために、しばしばお互いを理解していません。

オンボーディングSREチーム

これらの問題を解決し、SREへの移行を開始するために、オンボーディングプロジェクトを立ち上げました。それだけが古典的なオンボーディングではなかった-現在のチームに人々を追加するために新入社員（新人）を訓練した。これは、インフラストラクチャエンジニアとプログラマーの新しいチームの作成でした-本格的なSRE構造への第一歩。



プロジェクトに4か月を割り当て、3つの目標を設定しました。

1. インフラストラクチャチームでの職務と運用活動に必要な知識とスキルについてプログラマをトレーニングします。
2. IaCを記述-コード内のインフラストラクチャ全体の説明。そして、それはCI / CD、テストを備えた本格的なソフトウェア製品でなければなりません。
3. このコードからインフラストラクチャ全体を再作成し、Azureでマウスを使用して仮想マシンを手動でクリックすることを忘れます。

参加者：9人、そのうち6人は開発チーム、3人はインフラストラクチャ。4か月間、彼らは通常の仕事を辞めて、指定されたタスクに没頭する必要がありました。ビジネスの「生命」を維持するために、インフラストラクチャからさらに3人が勤務し、オペレーティングシステムを扱い、後方をカバーしました。その結果、プロジェクトは著しく伸び、5か月以上かかりました（2019年5月から10月まで）。

オンボーディングの2つの柱：学習と実践

オンボーディングは、トレーニングとコードによるインフラストラクチャの作業の2つの部分で構成されていました。



トレーニング。少なくとも1日3時間はトレーニングに割り当てられました。

• 参考文献のリストから記事や本を読む：Linux、ネットワーク、SRE;
• 特定のツールとテクノロジーに関する講義で;
• Linuxなどのテクノロジークラブで、複雑なケースとケースを分析しました。

もう1つの学習ツールは内部デモです。これは毎週の会議で、10分で全員（何か言いたいことがある人）が、彼らが1週間でコードに実装したテクノロジまたは概念について話しました。たとえば、VasyaはTerraformモジュールを操作するためのパイプラインを変更し、PetyaはPackerを使用してイメージアセンブリを書き直しました。



デモの後、私たちはSlackの各トピックの下でディスカッションを開始しました。そこでは、関心のある参加者がすべてを非同期でより詳細に議論することができました。したがって、10人での長い会議を避けましたが、同時に、チームの全員がインフラストラクチャで何が起こっているのか、どこに向かっているのかをよく理解していました。







練習。オンボーディングの2番目の部分は、コード内のインフラストラクチャの作成/説明です。この部分はいくつかの段階に分かれています。







インフラストラクチャのリバースエンジニアリング。これは、何がどこに展開され、どのように機能し、どのサービスが機能し、どのマシンとそのサイズが展開されるかを分析した最初の段階です。すべてが完全に文書化されました。



概念。私たちはさまざまなテクノロジー、言語、アプローチを実験し、インフラストラクチャをどのように説明できるか、どのツールを使用する必要があるかを発見しました。



スペルコード。これには、コード自体の記述、CI / CDパイプラインの作成、テスト、およびすべてのプロセスの構築が含まれます。説明したコードを記述し、開発インフラストラクチャをゼロから作成する方法を知っていました。



再作成とは、負荷テストと本番環境を意味します。これは、オンボーディング後に行われるはずだった4番目のステージですが、奇妙なことに、そこからの利益は、非常に頻繁に作成/再作成される未使用環境からの利益よりもはるかに少ないため、現時点では延期されています。



代わりに、プロジェクトアクティビティに切り替えました。小さなサブコマンドに分割し、これまでに到達していなかったグローバルインフラストラクチャプロジェクトを取り上げました。そしてもちろん、私たちは時計に参加しました。

インフラストラクチャでの極端なプログラミングプラクティス

プログラマーとして私たちが持ってきた主なものは、私たちが仕事で使用するエクストリームプログラミングの実践です。 XPは、最良の開発アプローチ、実践、および価値の絞り込みを組み合わせたアジャイルソフトウェア開発方法論です。



たとえそれについて知らなくても、エクストリームプログラミングの手法の少なくとも一部を使用しないプログラマは一人もいません。同時に、インフラストラクチャの世界では、これらのプラクティスは、Google SREのプラクティスと非常に重複しているにもかかわらず、バイパスされています。



XPをどのようにインフラストラクチャに適合させたかについての別の記事があります。。しかし、簡単に言うと、XPプラクティスは、制限や適応があっても、インフラストラクチャコードでも機能しますが、機能します。家でそれらを適用したい場合は、これらのプラクティスを適用した経験のある人を招待してください。これらのプラクティスのほとんどは、SREに関する同じ本で何らかの形で説明されています。



うまくいったかもしれませんが、そうはいきません。

途中で技術的および人為的な問題

プロジェクトには2種類の問題がありました。

• 技術的：「鉄」の世界の限界、他の人がいないために使用しなければならなかった知識と生のツールの欠如。これらはどのプログラマーにとっても一般的な問題です。
• 人間：チーム内の人々の相互作用。コミュニケーション、意思決定、トレーニング。これにより、状況は悪化したため、さらに詳しく説明する必要があります。

他のプログラミングチームと同じように、オンボーディングチームの開発を開始しました。タックマンによると、チームを形成する通常の段階があると予想していました：嵐、配給、そして最終的には生産性と生産的な仕事に行きます。したがって、彼らは当初、コミュニケーション、意思決定、同意するための困難がいくつかあることを心配していませんでした。



2か月が経過しましたが、嵐の段階は続きました。プロジェクトの終わり近くになって初めて、私たちが苦労し、互いに関連していると認識しなかったすべての問題は、共通の根本的な問題の結果であることがわかりました-まったく異なる人々の2つのグループがチームに集まった：

• 長年の経験を持つ経験豊富なプログラマーであり、彼らは仕事で独自のアプローチ、習慣、価値観を開発してきました。
• 独自の経験を持つインフラストラクチャの世界の別のグループ。彼らは異なる隆起、異なる習慣を持っています、そして彼らはまた、彼らが適切に生きる方法を知っていると思います。

1つのチームでの生活に関する2つの見方の衝突がありました。私たちはすぐにそれを見ることはできず、作業を開始できなかったため、多くの時間、エネルギー、神経を失っていました。



しかし、この衝突を回避することは不可能です。強力なプログラマーと弱いインフラストラクチャエンジニアをプロジェクトに招待すると、知識が一方向に交換されます。それどころか、それも機能しません-他の人を飲み込む人もいます。そして、特定の混合物を取得する必要があるため、「研削」が非常に長くなる可能性があるという事実に備える必要があります（この場合、1年後にはチームを安定させることができましたが、最も技術的に強力なエンジニアの1人に別れを告げました）。



そのようなチームだけを編成したい場合は、強力なアジャイルコーチ、スクラムマスター、または心理療法士に電話することを忘れないでください。多分彼らは助けるでしょう。

オンボーディング結果

オンボーディングプロジェクト（2019年10月に終了）の結果に基づいて、次のことを行いました。

• 独自のCIパイプラインを備えたDEVインフラストラクチャを管理し、高品質のソフトウェア製品のテストやその他の属性を備えた、本格的なソフトウェア製品を作成しました。
• 勤務の準備ができている人の数を倍増させ、現在のチームの負担を取り除きました。6か月後、これらの人々は本格的なSREになりました。これで、市場に火をつけたり、NTFのプログラマーチームに相談したり、開発者向けに独自のライブラリを作成したりできます。
• SRE. , , .
• : , , , .

: ,

開発者からのいくつかの洞察。私たちの熊手を踏まないでください、あなた自身と他の神経と時間を節約してください。



インフラストラクチャーは過去のものです。新入生（15年前）でJavaScriptの学習を始めたとき、デバッグ用にNotePad ++とFirebugを用意していました。それでも、これらのツールを使用して複雑で美しいことを行う必要がありました。



インフラストラクチャを操作するときと同じように感じます。現在のツールのみが作成されており、それらの多くはまだリリースされておらず、バージョン0.12（hi、Terraform）であり、多くのツールは以前のバージョンとの下位互換性を定期的に壊しています。



私にとって、エンタープライズ開発者として、このようなものを本番環境で使用するのはばかげています。しかし、他にはありません。



ドキュメントをお読みください。プログラマーとして、私がドックに行くことはめったにありません。私は自分のツールを十分に理解していました。私の好きなプログラミング言語、私の好きなフレームワークとデータベースです。ライブラリなどのすべての追加ツールは通常同じ言語で記述されているため、いつでもソースコードを確認できます。 IDEは常に、必要なパラメータと場所を通知します。私が間違っていても、簡単なテストを実行することですぐにわかります。



これはインフラストラクチャでは機能しません。知っておく必要のあるさまざまなテクノロジが多数あります。しかし、すべてを深く知ることは不可能であり、多くは未知の言語で書かれています。したがって、ドキュメントを注意深く読んで（そして書いて）ください。彼らはこの習慣がないとここに長く住んでいません。



インフラストラクチャコード内のコメントは避けられません。開発の世界では、コメントは悪いコードの兆候です。彼らはすぐに時代遅れになり、嘘をつき始めます。これは、開発者が他の方法で自分の考えを表現できなかったことを示しています。インフラストラクチャで作業する場合、コメントも悪いコードの兆候ですが、コメントなしでは実行できません。お互いにゆるく関連していて、お互いについて何も知らない散らばった楽器には、コメントが不可欠です。



多くの場合、コードの下では、通常の構成とDSLは隠されています。この場合、すべてのロジックは、アクセスされていない、より深い場所で発生します。これにより、コードへのアプローチ、テスト、コードの使用方法が大きく変わります。



開発者がインフラストラクチャに入るのを恐れないでください。彼らは、ソフトウェア開発の世界から有用な（そして新鮮な）プラクティスとアプローチをもたらすことができます。SREについての本に記載されているGoogleのプラクティスとアプローチを使用して、利益を上げて幸せになります。

PS: , , , .



PPS: DevOpsConf 2019 . , , : , , DevOps-, .



PPPS: , DevOps-, DevOps Live 2020. : , - . , DevOps-. — « » .



, DevOps Live , , CTO, .