DevOpsのテキスト研修
日々のDevOpsの実践を組織の学びにつなげるには
DevOpsの主要な原則の一つは、チームで日々の仕事から学び続け、その学びを、組織全体で再利用できる資産に変えることです。
チャットルームで知識を広げる
チャットルームを使って組織の知識を記録し、新たに作ります。チャットルームと連携するボットを作り、運用作業をすばやく実行できるようにします。たとえば、チャットルームでボットに次のメッセージを送ると、FrontEndAppをTestServer-9環境にインストールできます。コマンドラインで実行したときのように、実行結果がチャットルームに返ります。
@bot install FrontEndApp TestServer-9
この仕組みがあれば、チームの全員が作業の進捗をすばやく共有できます。個別のメッセージやメールの中に情報が埋もれることもありません。仕事で協働し、情報をオープンにする文化が育ちます。個々の現場の知識を組織の学びに変えるうえで、非常に効果的な方法です。
共通のチャットルームを使うことで、DevOpsチームや会社に新しく加わった人が、早く仕事に慣れることもできます。自分のチームで作業がどう進むか、その多くを簡単に観察できるからです。製品、サービス、コンポーネント、ツール、ライブラリ、連携ごとにチャットルームを分ければ、システム内の特定の要素に関する過去の活動を検索し、見つけやすくなります。
実行可能な形で知識を残す
ノウハウや専門知識を文書やWikiに記すだけでなく、標準や手順をできる限り実行可能な形で作ります。DevOps組織で知識を作り、共有する最良の方法の一つは、再利用できるツールを作り、必要な人が見つけられるようソースコードのバージョン管理システムに保存することです。読み手によって解釈が異なったり誤解が生じたりする静的な文書ではなく、標準と作業手順を実行可能なコードで表せば、業務が速く簡単になります。さらに、監査やコンプライアンスが必要な手順をコードがどのように処理するか説明する簡潔な文書があれば、さまざまな監査やコンプライアンス確認にも対応しやすくなります。
自動化できない作業、プロセス、標準については、手順が明確に分かれ、チェックリストが付いた、再利用可能なユーザーストーリーを作ります。DevOps組織の全員が、その資産を再利用して恩恵を受けられます。異なるチームが似た仕事を一貫した方法で行い、コードライブラリを継続的にレビュー、再利用、改善するのと同じように、これらの資産も改善できます。
再利用可能なソフトウェアのひな型を作る
非機能要件への対応を設計段階で組み込んだ、コンポーネント、アプリケーション、サービス、マイクロサービスのひな型を作ります。開発者は新しいコードを書くたびに、非機能要件への対応を一から考える必要がなくなります。
また、アプリケーションスタック全体で一貫した非機能要件を実装できます。非機能面の機能を組み込むことで、テスト環境や本番環境でのデプロイ、監視、トラブルシューティング、その他の運用も簡素になります。次のような非機能要件が例です。
- テレメトリのメトリクス。
- 実行時設定。
- フィーチャートグル。
- 依存関係を追跡できること。
- ユーザーが発行したリクエストを追跡できる機能。
- 回復力と耐障害性を備えたサービス。
- 必要に応じて、支障を抑えながら段階的に機能を縮小できるサービス。
- ログメッセージを検索できること。
- 旧バージョンと将来のバージョンとの互換性。
- 本番データセットのアーカイブと管理。
- ログの管理とアーカイブ。
コード化したひな型には、網羅的な自動テストを組み込みます。自動テストによって、コードの目的と再利用可能なコードの効率的な使い方が明らかになります。ひな型をもとにした独自のアプリケーション用の自動テストも、より早く作れます。
単一のコードリポジトリを使う
学んだことと作業の内容を全員で共有するため、一つのリポジトリにソースコードを保存するだけでなく、デプロイ用ツール、デプロイメントパイプラインを構築し実行するコード、自動テスト、テレメトリを作り統合するコード、標準、チュートリアル、文書、Wiki、補助ツール、プラットフォームの設定標準も保存します。
こうすることで、DevOps組織の誰もがすべての資産を参照できます。同じ成果物、コンポーネント、サードパーティ製ツールの重複や、複数バージョンの混在も防げます。単一のリポジトリがあれば、実行時にすべてをコンパイル、リンク、ビルドでき、ソフトウェアの開発、テスト、デプロイで、あらゆるものの最新版を使えます。
技術標準を定め、柔軟性を保つ
DevOpsチームの全員が互いのコードを読み、レビューし、修正できるようにしたいなら、開発と運用のメンバーがみな習得し、使える主な技術標準を定めます。必要なのは、コンパイル型言語を一つ、スクリプト言語を一つ、GUI用言語を一つです。それでも、全員が関心のある技術を自由に探究できるようにして、チームが学び、実験を続けられるようにしましょう。既存の枠の外で探究し、試さずに、次の革新でどう成功するのでしょうか。
まとめ
この章では、日々の仕事を通じてDevOps組織が学び、資産を作れるようにする、広く受け入れられている手法をいくつか紹介しました。これらを活用すると、組織全体に蓄積された経験と専門知識が、DevOpsチームの一人ひとりの専門性と仕事の質を支え、高めます。
あなたのDevOpsの歩みが実りあるものになりますように。
