コードとしてのインフラストラクチャ: XP を使用して問題を解決する方法

こんにちは、ハブル！ 以前、私はコードパラダイムとしてのインフラストラクチャの生活について不平を言いましたが、現在の状況を解決するために何も提供しませんでした。 今日は、あなたが絶望のどん底から抜け出し、状況を正しい方向に導くのにどのようなアプローチと実践が役立つかをお伝えするために戻ってきました。

前回の記事で 「コードとしてのインフラストラクチャ: 初めての知り合い」 私はこの分野についての感想を共有し、この分野の現在の状況を考察し、すべての開発者に知られている標準的な手法が役に立つかもしれないとさえ提案しました。 生活についての不満はたくさんあるように見えますが、現状を打開するための提案はありませんでした。

私たちは誰なのか、どこにいるのか、どんな問題を抱えているのか

私たちは現在、XNUMX 人のプログラマーと XNUMX 人のインフラストラクチャ エンジニアで構成される Sre オンボーディング チームに所属しています。 私たちは皆、コードとしてインフラストラクチャ (IaC) を書こうとしています。 私たちがこれを行うのは、基本的にコードの書き方を知っており、「平均以上」の開発者としての経歴があるからです。

• 私たちには、一定の背景、実践に関する知識、コードを書く能力、新しいことを学びたいという意欲など、一連の利点があります。
• また、インフラストラクチャのハードウェアに関する知識が不足しているというマイナス面もあります。

IaC で使用するテクノロジー スタック。

• リソースを作成するための Terraform。
• イメージを組み立てるためのパッカー。 これらは Windows、CentOS 7 イメージです。
• Jsonnet を使用して、Drone.io で強力なビルドを作成し、パッカー JSON と Terraform モジュールを生成します。
• アズール。
• イメージを準備するときの Ansible。
• 補助サービスとプロビジョニング スクリプト用の Python。
• これらはすべて、チーム メンバー間で共有されるプラグインを使用して VSCode で実行されます。

私からの結論 前回の記事 私は（まず第一に自分自身に）楽観主義を植え付けようとしました。この分野に存在する困難と複雑さに対処するために、私たちが知っているアプローチと実践を試してみると言いたかったのです。

現在、次の IaC の問題に悩まされています。

• コード開発のためのツールと手段が不完全。
• 導入が遅い。 インフラストラクチャは現実世界の一部であるため、速度が遅くなる場合があります。
• アプローチと実践の欠如。
• 私たちは新しくて、あまり知りません。

エクストリーム プログラミング (XP) が助けになります

すべての開発者は、エクストリーム プログラミング (XP) とその背後にある実践に精通しています。 私たちの多くはこのアプローチに取り組み、成功を収めてきました。 そこで、インフラストラクチャの課題を克服するために、そこに定められた原則と実践を活用してみてはいかがでしょうか? 私たちはこのアプローチを採用して何が起こるかを確認することにしました。

XP アプローチの業界への適用可能性を確認するXP が最適な環境と、それが私たちにどのような関係があるのか​​について説明します。

1. 動的に変化するソフトウェア要件。 最終目標が何であるかは私たちにとって明らかでした。 ただし、詳細は異なる場合があります。 タクシーに乗る必要がある場所は私たち自身で決定するため、要件は定期的に（主に私たち自身によって）変更されます。 SRE チームを例​​にとると、自動化自体を行い、それ自体が要件と作業範囲を制限するため、この点はうまく当てはまります。

2. 新しいテクノロジーを使用した固定期間プロジェクトによって引き起こされるリスク。 未知のものを使用すると、リスクに遭遇する可能性があります。 そしてこれは100%私たちのケースです。 私たちのプロジェクト全体では、私たちが十分に慣れていないテクノロジーが使用されていました。 一般に、これは常に発生する問題です。 インフラ分野では常に多くの新しいテクノロジーが登場しています。

3,4. 小規模で、同じ場所に配置された拡張開発チーム。 使用している自動化テクノロジーにより、単体テストと機能テストが可能になります。 この 14 点が私たちにはまったく合いません。 第一に、私たちは調整されたチームではありません。第二に、私たちのメンバーは XNUMX 人であり、大規模なチームと言えます。 ただし、「大規模な」チームの定義によれば、多くは XNUMX 人以上です。

XP の実践例と、それがフィードバックの速度と品質にどのような影響を与えるかを見てみましょう。

XP フィードバック ループの原理

私の理解では、フィードバックは、自分がやっていることが正しいのか、そこに向かって進んでいるのか、という質問に対する答えです。 XP には、このための神聖なスキーム、つまり時間フィードバック ループがあります。 興味深いのは、順位が低いほど、OS が必要な質問に早く答えることができるということです。

これは非常に興味深い議論のテーマです。私たちの IT 業界では、OS をすぐに入手できるということです。 プロジェクトを XNUMX か月間実行し、その後になって初めて最初の段階で間違いがあったことに気づくのがどれほど苦痛かを想像してみてください。 これは、設計や複雑なシステムの構築において発生します。

IaC の場合、フィードバックが役に立ちます。 すぐに上の図に少し調整を加えます。リリース計画には毎月のサイクルはありませんが、XNUMX 日に数回発生します。 この OS サイクルに関連する実践方法がいくつかありますが、これについては後で詳しく説明します。

重要: フィードバックは、上記のすべての問題の解決策となる可能性があります。 XP の実践と組み合わせることで、絶望の淵から抜け出すことができます。

絶望の淵から抜け出す方法: XNUMX つの実践方法

テスト

XP フィードバック ループではテストについて XNUMX 回言及されています。 それだけではありません。 これらは、エクストリーム プログラミング手法全体にとって非常に重要です。

単体テストと受け入れテストがあることを前提としています。 フィードバックが数分で届くものもあれば、数日かかるものもあり、作成に時間がかかり、レビューの頻度も低くなります。

古典的なテスト ピラミッドがあり、テストをもっと増やす必要があることを示しています。

このフレームワークは IaC プロジェクトにどのように適用されますか? 実は…全然違います。

• 単体テストはたくさんあるべきですが、多すぎることはできません。 あるいは、非常に間接的に何かをテストしている場合もあります。 実際、私たちはそれらをまったく書いていないと言えます。 ただし、私たちが実行できたそのようなテストの応用例をいくつか紹介します。
  1. jsonnetコードのテスト。 たとえば、これは当社のドローン組立パイプラインですが、非常に複雑です。 jsonnet コードはテストで十分にカバーされています。
     うちはこれを使ってます Jsonnet の単体テスト フレームワーク.
  2. リソースの開始時に実行されるスクリプトをテストします。 スクリプトは Python で記述されるため、スクリプト上でテストを作成できます。
• テストで構成をチェックすることは潜在的に可能ですが、私たちはそれを行いません。 リソース設定ルールのチェックを設定することもできます。 フリント。 ただし、そこでのチェックは Terraform にとっては基本的すぎるものですが、多くのテスト スクリプトは AWS 向けに作成されています。 また、私たちは Azure を使用しているため、これも当てはまりません。
• コンポーネント統合テスト: それは、コンポーネントをどのように分類し、どこに配置するかによって異なります。 しかし、それらは基本的に機能します。

  統合テストは次のようになります。

  
  
  Drone CIで画像を構築する場合の例です。 これらに到達するには、Packer イメージが形成されるまで 30 分間待機し、それが通過するまでさらに 15 分間待つ必要があります。 しかし、それらは存在します！

  画像検証アルゴリズム

  1. Packer はまずイメージを完全に準備する必要があります。
  2. テストの隣にはローカル状態を含む Terraform があり、このイメージをデプロイするために使用します。
  3. 展開するとき、画像の操作を容易にするために近くにある小さなモジュールが使用されます。
  4. VM がイメージからデプロイされると、チェックを開始できます。 基本的には車上での点検となります。 起動時にスクリプトがどのように動作するか、およびデーモンがどのように動作するかをチェックします。 これを行うには、ssh または winrm 経由で新しく起動したマシンにログインし、構成ステータスまたはサービスが稼働しているかどうかを確認します。

• 状況は、terraform のモジュールの統合テストでも同様です。 以下に、そのようなテストの特徴を説明した短い表を示します。

  
  
  パイプラインのフィードバックには約 40 分かかります。 すべては非常に長い間起こります。 回帰には使用できますが、新規開発には一般に非現実的です。 これに対して十分な準備ができていれば、実行スクリプトを準備すれば、時間を 10 分に短縮できます。 ただし、これらは 5 秒間で 100 個のテストを実行する単体テストではありません。

イメージや terraform モジュールを組み立てるときに単体テストがないため、単純に REST 経由で実行できる別個のサービスや Python スクリプトに作業を移すことが推奨されます。

たとえば、仮想マシンの起動時に、仮想マシン自体がサービスに登録されることを確認する必要がありました。 スケールFT、仮想マシンが破棄されると、仮想マシン自体も削除されました。

サービスとして ScaleFT があるため、API を介してそれを操作する必要があります。 そこにはラッパーが書かれていて、それを引っ張って「これとこれを削除してください」と言うことができました。 必要な設定とアクセスがすべて保存されます。

これは通常のソフトウェアと何ら変わらないため、すでに通常のテストを作成できます。ある種の apiha をモック化し、それをプルして、何が起こるかを確認します。

テストの結果: 単体テストでは XNUMX 分で OS が得られるはずですが、結果が得られません。 また、ピラミッドの上位にあるタイプのテストは効果的ですが、問題の一部しかカバーしません。

ペアプログラミング

テストはもちろん良いです。 さまざまな種類のメッセージをたくさん書くことができます。 彼らは自分のレベルに応じて働き、私たちにフィードバックを与えてくれます。 しかし、最速の OS を提供する不適切な単体テストの問題は依然として残ります。 同時に、私は依然として、操作が簡単で快適な、高速な OS を望んでいます。 結果として得られるソリューションの品質は言うまでもありません。 幸いなことに、単体テストよりもさらに高速なフィードバックを提供できる手法があります。 これがペアプログラミングです。

コードを作成するときは、その品質に関するフィードバックをできるだけ早く得たいと考えます。 はい、フィーチャー ブランチにすべてを記述し (誰にも何も壊さないように)、Github でプル リクエストを作成し、意見に重みがある人にそれを割り当て、応答を待つことができます。

しかし、長い間待つこともできます。 人々は皆忙しいので、たとえ答えがあったとしても、その答えは最高の品質ではない可能性があります。 答えがすぐに出た場合、レビュー担当者はアイデア全体を瞬時に理解しましたが、答えはまだ遅く、事後になって出てくるとします。 もっと早ければよかったのに。 これがペア プログラミングの目的です。この記事の執筆時点ですぐにわかります。

以下は、ペアのプログラミング スタイルと、IaC での作業におけるそれらの適用性です。

1. クラシック、経験者+経験者、タイマーによるシフト。 ドライバーとナビゲーターのXNUMX役。 二人。 彼らは同じコードで作業し、あらかじめ決められた一定期間の後に役割を切り替えます。

私たちの問題とスタイルの互換性を考えてみましょう。

• 問題: コード開発用のツールとツールの不完全さ。
  マイナスの影響: 開発に時間がかかり、速度が低下し、仕事のペースやリズムが失われます。
  戦い方: 異なるツールや共通の IDE を使用し、ショートカットも学習します。
• 問題: 導入が遅い。
  悪影響: 実用的なコードの作成にかかる時間が増加します。 待っている間、私たちは退屈し、待っている間に何か他のことをしようと手を伸ばします。
  私たちの戦い方：私たちはそれを克服できませんでした。
• 問題: アプローチと実践の欠如。
  マイナスの影響: うまくやる方法と下手なやり方についての知識がありません。 フィードバックを受け取る時間が長くなります。
  戦い方：ペアワークでお互いの意見を交換し実践することで問題はほぼ解決します。

IaC でこのスタイルを使用する場合の主な問題は、作業のペースが不均一であることです。 従来のソフトウェア開発では、非常に均一な動きが行われます。 10 分かけて N を書きます。2 分かけて 15N、3 分 - 30N と書きます。 ここでは、XNUMX 分かけて N を書き、さらに XNUMX 分かけて N の XNUMX 分の XNUMX を書きます。ここでは何も知らず、行き詰まっています、愚か者です。 調査には時間がかかり、プログラミング自体に集中できなくなります。

結論：純粋な形では私たちには適していません。

2. ピンポン。 このアプローチでは、XNUMX 人がテストを作成し、もう XNUMX 人がテストの実装を行います。 単体テストではすべてが複雑で、プログラミングに長時間かかる統合テストを作成する必要があるという事実を考慮すると、ピンポンの容易さはすべて失われます。

テスト スクリプトの設計とそのコードの実装の責任を分離しようとしたと言えます。 参加者の XNUMX 人が脚本を考え出しました。彼が担当する作業のこの部分では、彼が最後の決定権を持っていました。 そしてもう一人は実装を担当しました。 うまくいきました。 このアプローチによりスクリプトの品質が向上します。

結論: 残念ながら、作業のペースを考慮すると、IaC でのペア プログラミングの練習としてピンポンを使用することはできません。

3.強いスタイル。 難しい練習。 このアイデアは、XNUMX 人の参加者がディレクティブ ナビゲーターになり、XNUMX 番目の参加者が実行ドライバーの役割を担うというものです。 この場合、決定権はナビゲーターのみにあります。 ドライバーは印刷のみを行い、単語の動作に影響を与えることができます。 役割は長い間変わりません。

学習には適していますが、強力なソフトスキルが必要です。 ここで私たちはつまずいたのです。 技術が難しかったです。 そしてそれはインフラストラクチャに関するものではありません。

結論: 使用できる可能性はあります。私たちは試すことを諦めていません。

4. モビング、スワーミング、および既知だがリストされていないすべてのスタイル 私たちはそれを考慮していません。 私たちはそれを試したことはありませんし、私たちの仕事の文脈でそれについて話すことは不可能です。

ペア プログラミングを使用した場合の一般的な結果:

• 仕事のペースにばらつきがあり、混乱しています。
• ソフトスキルが不十分であることに遭遇しました。 そして、この主題領域は、私たちのこれらの欠点を克服するのに役立ちません。
• 長時間にわたるテストやツールの問題により、ペア開発が困難になります。

5. それにもかかわらず、成功もありました。 私たちは独自の手法「収束－発散」を考案しました。 その仕組みを簡単に説明します。

数日間（XNUMX週間未満）の常駐パートナーがいます。 私たちは一つの仕事を一緒にやります。 私たちはしばらく一緒に座って、XNUMX人が書き、もうXNUMX人が座ってサポートチームを観察します。 それから私たちはしばらく解散し、それぞれがいくつかの独立したことをし、それから再び集まり、すぐに同期し、一緒に何かをして、再び解散します。

企画とコミュニケーション

OS の問題を解決するための実践の最後のブロックは、タスク自体の作業を組織化することです。 これには、ペアワーク以外の経験の交換も含まれます。 XNUMX つの実践方法を見てみましょう。

1. ゴールツリーによる目標。 プロジェクト全体の管理を、無限に未来へ続くツリーで整理しました。 技術的には、追跡は Miro で行われます。 タスクは XNUMX つあり、それは中間目標です。 そこから、より小さな目標またはタスクのグループが作成されます。 タスク自体は彼らから生まれます。 すべてのタスクはこのボード上で作成および管理されます。

このスキームはフィードバックも提供します。フィードバックは、ラリーで同期するときに XNUMX 日に XNUMX 回発生します。 全員の前で共通の計画を立て、構造化され完全にオープンにすることで、何が起こっているのか、どこまで進んでいるのかを全員が認識できるようになります。

タスクを視覚化する利点:

• 因果関係。 それぞれのタスクは、何らかのグローバルな目標につながります。 タスクは小さな目標にグループ化されます。 インフラストラクチャ ドメイン自体は非常に技術的です。 たとえば、別の nginx への移行に関するランブックを作成することがビジネスにどのような具体的な影響を与えるかがすぐに明らかになるわけではありません。 ターゲットのカードが近くにあると、より明確になります。
  
  因果関係は問題の重要な特性です。 「私は正しいことをしているのだろうか?」という質問に直接答えます。
• 並列処理。 私たちには XNUMX 人がいますが、全員に XNUMX つのタスクを任せるのは物理的に不可能です。 XNUMX つの分野のタスクだけでは必ずしも十分とは限りません。 私たちは小さな作業グループ間で作業を並行して行うことを余儀なくされています。 同時に、グループはしばらくの間自分のタスクに取り組み、他の誰かによって強化される可能性があります。 時々、この作業グループから離れてしまう人もいます。 誰かが休暇に行き、誰かがDevOps confのレポートを作成し、誰かがHabrに関する記事を書きます。 どのような目標とタスクを並行して実行できるかを知ることが非常に重要になります。

2. 朝礼の司会者の交代。 スタンドアップではこの問題があります。人々は多くのタスクを並行して実行します。 場合によっては、タスクのつながりが緩く、誰が何をしているのかが理解できない場合があります。 そして、他のチームメンバーの意見は非常に重要です。 これは、問題解決の方向性を変える可能性がある追加情報です。 もちろん、通常は誰かがあなたと一緒にいますが、アドバイスやヒントは常に役に立ちます。

この状況を改善するために、私たちは「先頭のスタンドアップを変更する」テクニックを適用しました。 現在、それらは特定のリストに従ってローテーションされており、これが効果をもたらします。 自分の番が来たら、適切なスクラム ミーティングを運営するために、何が起こっているのかを理解する必要があります。

3. 内部デモ。 ペアプログラミングによる問題解決の支援、問題ツリー上の視覚化、朝のスクラムミーティングでの支援は良いことですが、理想的ではありません。 カップルとして、あなたはあなたの知識によってのみ制限されます。 タスク ツリーは、誰が何をしているのかを全体的に理解するのに役立ちます。 そして、朝礼の発表者や同僚は、あなたの問題を深く掘り下げることはありません。 確かに彼らは何かを見逃しているかもしれません。

解決策は、お互いに行った作業をデモンストレーションし、それについて話し合うことで見つかりました。 私たちは週に一度 XNUMX 時間集まり、過去 XNUMX 週間に行ったタスクの解決策の詳細を示します。

デモンストレーションでは、タスクの詳細を明らかにし、その動作を確実にデモンストレーションする必要があります。

レポートはチェックリストを使用して実行できます。1. コンテキストに入ります。 そのタスクはどこから来たのか、なぜそれが必要だったのでしょうか?

2. その問題は以前どのように解決されましたか? たとえば、マウスを大量にクリックする必要があったり、まったく操作が不可能だったりします。

3. それをどのように改善するか。 例: 「ほら、scriptosik があります。これが Readme です。」

4. それがどのように機能するかを示します。 いくつかのユーザー シナリオを直接実装することをお勧めします。 私は X が欲しい、私は Y をする、私は Y (または Z) を見ます。 たとえば、NGINX をデプロイし、URL をスモークし、200 OK を取得します。 アクションが長い場合は、後で見せられるように事前に準備してください。 壊れやすい場合は、デモの XNUMX 時間前にあまり壊さないことをお勧めします。

5. 問題がどの程度うまく解決されたか、どのような困難が残っているか、何が未完了であるか、将来どのような改善が可能かを説明します。 たとえば、現在は CLI ですが、その後は CI で完全な自動化が行われるようになります。

各スピーカーの持ち時間を 5 ～ 10 分に抑えることをお勧めします。 スピーチが明らかに重要であり、時間がかかる場合は、事前に sre-takeover チャネルで調整してください。

対面パートの後は常にスレッド内でディスカッションが行われます。 ここには、タスクに関して必要なフィードバックが表示されます。

その結果、起こっていることの有用性を判断するために調査が実施されます。 これは、スピーチの本質とタスクの重要性に関するフィードバックです。

長い結論と今後の展開

記事の論調はやや悲観的であるように思われるかもしれません。 これは間違っています。 XNUMX つの下位レベルのフィードバック、つまりテストとペア プログラミングが機能します。 従来の開発ほど完璧ではありませんが、プラスの効果はあります。

現在の形式では、テストは部分的なコード カバレッジのみを提供します。 多くの構成機能はテストされずに終わります。 コードを記述する際の実際の作業への影響は低いです。 ただし、結合テストの効果があり、恐れることなくリファクタリングを実行できます。 これは素晴らしい成果です。 また、高級言語 (Python や Go など) での開発に焦点を移すことで、問題は解決します。 また、「接着剤」について多くのチェックを行う必要はなく、一般的な統合チェックで十分です。

ペアで作業する場合は、特定の人に依存することが多くなります。 タスク要因と私たちのソフトスキルがあります。 とてもうまくいく人もいれば、うまくいかない人もいます。 これによるメリットは間違いなくあります。 たとえペアワークのルールが十分に守られていないとしても、タスクを一緒に実行するという事実自体が結果の質にプラスの影響を与えることは明らかです。 個人的には、ペアで作業する方が簡単で楽しいと思います。

OS に影響を与えるより高いレベルの方法 - タスクの計画と作業を正確に行うことで、高品質の知識交換と開発品質の向上という効果が生まれます。

短い結論を XNUMX 行でまとめる

• 人事担当者は IaC で作業しますが、効率は低下します。
• 機能するものを強化します。
• 独自の代償メカニズムと実践方法を考え出します。

出所： habr.com