記事の翻訳はコースの学生向けに特別に用意されました 、今日から始まります！
新しいサービスを本番環境にリリースしたことがありますか?それとも、そのようなサービスのサポートに携わっていたのでしょうか？ 「はい」の場合、何があなたを動機づけましたか?生産にとって何が良いのか、何が悪いのか?既存のサービスのリリースやメンテナンスについて、新しいチーム メンバーをどのようにトレーニングしますか。
ほとんどの企業は、産業運営慣行に関して「西部開拓時代」のアプローチを採用することになります。各チームは試行錯誤を通じて独自のツールとベスト プラクティスを決定します。しかし、これはプロジェクトの成功だけでなく、エンジニアにも影響を与えることがよくあります。
試行錯誤により、非難や責任転嫁が頻繁に行われる環境が生まれます。このような行動をとると、間違いから学び、二度と同じことを繰り返さないことがますます困難になります。
成功している組織:
- 制作のためのガイドラインの必要性を認識し、
- ベストプラクティスを研究し、
- 新しいシステムまたはコンポーネントを開発する際に、実稼働準備の問題について議論を開始します。
- 生産準備のルールを確実に遵守します。
制作の準備には「レビュー」という工程があります。レビューはチェックリストまたは一連の質問の形式で行うことができます。レビューは手動、自動、またはその両方で行うことができます。要件の静的なリストの代わりに、特定のニーズに適応できるチェックリスト テンプレートを作成できます。これにより、エンジニアは必要に応じて知識を継承し、十分な柔軟性を得ることができます。
サービスが実稼働の準備ができているかどうかをいつ確認するか?
リリース直前だけでなく、別の運用チームや新入社員に移管する際にも本番準備状況チェックを実施すると便利です。
次の場合に確認してください。
- 新しいサービスを実稼働環境にリリースしようとしています。
- 実稼働サービスの運用を SRE などの別のチームに移管します。
- 本番サービスの運用を新しい従業員に移管します。
- 技術サポートを組織します。
本番準備チェックリスト
少し前の例ですが、私は 本番環境への準備状況をテストするためのチェックリスト。このリストは Google Cloud の顧客向けに作成されたものですが、Google Cloud の外部でも役立ち、適用できるものです。
デザインと開発
- 外部サービスへのアクセスを必要とせず、外部システムの障害に依存しない、反復可能なビルド プロセスを開発します。
- 設計および開発期間中に、サービスの SLO を定義および設定します。
- 依存している外部サービスの可用性についての期待を文書化します。
- 単一のグローバル リソースへの依存関係を削除して、単一障害点を回避します。リソースをレプリケートするか、リソースが使用できない場合はフォールバックを使用します (ハードコーディングされた値など)。
構成管理
- 静的で小規模な非機密構成は、コマンド ライン パラメーターを介して渡すことができます。それ以外の場合は、構成ストレージ サービスを使用します。
- 動的構成には、構成サービスが使用できない場合に備えてフォールバック設定が必要です。
- 開発環境の構成は運用環境の構成と関連していてはなりません。そうしないと、開発環境から本番サービスへのアクセスが発生し、プライバシーの問題やデータ漏洩が発生する可能性があります。
- 動的に構成できる内容を文書化し、構成配信システムが使用できない場合のフォールバック動作について説明します。
リリース管理
- リリースプロセスを詳細に文書化します。リリースが SLO にどのような影響を与えるかを説明します (たとえば、キャッシュ ミスによるレイテンシの一時的な増加など)。
- カナリアリリースを文書化します。
- カナリア リリースのレビュー計画を作成し、可能であれば自動ロールバック メカニズムを作成します。
- ロールバックでデプロイメントと同じプロセスを使用できることを確認してください。
可観測性
- SLO に必要なメトリックのセットが収集されていることを確認します。
- クライアント データとサーバー データを区別できるようにしてください。これは故障の原因を究明するために重要です。
- アラートを設定して人件費を削減します。たとえば、日常的な操作によって発生するアラートを削除します。
- Stackdriver を使用している場合は、ダッシュボードに GCP プラットフォームの指標を含めます。 GCP の依存関係に関するアラートを設定します。
- 受信トレースを常に伝播します。トレースに関与していない場合でも、これにより、下位レベルのサービスが運用環境の問題をデバッグできるようになります。
保護と安全
- すべての外部接続が暗号化されていることを確認してください。
- 実稼働プロジェクトに正しい IAM 設定があることを確認してください。
- ネットワークを使用して、仮想マシン インスタンスのグループを分離します。
- VPN を使用してリモート ネットワークに安全に接続します。
- ユーザーのデータへのアクセスを文書化して監視します。データへのすべてのユーザー アクセスが監査され、ログに記録されるようにします。
- デバッグ エンドポイントが ACL によって制限されていることを確認します。
- ユーザー入力をサニタイズします。ユーザー入力のペイロード サイズ制限を構成します。
- サービスが個々のユーザーの受信トラフィックを選択的にブロックできることを確認してください。これにより、他のユーザーに影響を与えることなく違反がブロックされます。
- 多くの内部操作を開始する外部エンドポイントは避けてください。
キャパシティプランニング
- サービスがどのように拡張されるかを文書化します。例: ユーザーの数、受信ペイロードのサイズ、受信メッセージの数。
- サービスのリソース要件を文書化します。例: 専用仮想マシン インスタンスの数、Spanner インスタンスの数、GPU や TPU などの特殊なハードウェア。
- リソースの制限を文書化します: リソースの種類、地域など。
- 新しいリソースを作成するためのクォータ制限を文書化します。たとえば、API を使用して新しいインスタンスを作成する場合は、GCE API リクエストの数を制限します。
- パフォーマンスの低下を分析するために負荷テストを実行することを検討してください。
それだけです。また授業で会おう！
出所： habr.com