https://medium.com/@rakyll/production-guideline-9d5d10c8f1e を勝手に翻訳したものです。個人の感想を含みます。日本語母国語じゃないので誤字脱字及び理解の誤りなどがある可能性がありますのでご指摘または編集リクエストいただけるとありがたいです。
設計と開発
- ビルドは外部サービスなどから影響を受けない再現性のあるプロセスにしましょう。
- 設計時にサービスの SLO (サービスレベル目標) を定義しましょう
- 外部サービスの可用性のレベルを文書化しましょう
- 単一のグローバルなリソースに依存せず、複数またはフォールバックプラン（ハードコードなどでも）して置きましょう
構成管理
- 気密的な情報ではない静的かつ小規模な制定はコマンドラインフラグでも大丈夫ですが、その他はすべて設定管理サービスを利用してください。
- 動的設定はその設定管理サービスが利用できないときにファールバックの設定を持つようにしてください。
- 開発環境の設定は本番から継承することはやめましょう。プライバシーとデータ漏洩を起す恐れがあります。
- 動的に設定できるものを文書化し、設定管理サービスが利用できない場合の動作の説明も書きましょう
リリース管理
- リリースプロセスはすべて文書化しましょう。
- SLO に影響を与えることも文書化しましょう。(例：キャッシュミスによる一時的な待ち時間の増加)
- カナリリリースプロセスがあれば文書化しましょう。自動的にフォールバックとか、分析できる仕組みを用意しましょう
- ロールバックではロールアウトと同じプロセスを使うようにしましょう
可観測性
- SLO に必要なメトリックスが収集されていることを確認しましょう
- クライアント側とサーバー側のデータは区別出来るようにしましょう。本番環境でもデバッグするためには重要です。
- 通常な作業などによるアラートは減らすようにしましょう
- Stackdriver 利用している場合はダッシュボードに GCP の指標も含みましょう
- トレースコンテキストを追加しましょう。gRPCの場合 grpc-trace-bin、HTTP の場合は X-Cloud-Trace-Context ヘッダーを参照してください。GCP側で問題をデバッグすることが可能になります。
- Stackdriver Profiler を有効化して CPU の使用率を最適化しましょう
セキュリティと保護
- 外部通信は暗号化されていることを確認しましょう
- 本番環境の IAM が適切であることを確認しましょう
- プロジェクトに使っているリソースを完全に分離しましょう
- プロジェクト内のネットワークを使用し、VMインスタンスをグループ分けしましょう
- Cloud VPN サービスを使ってリモートネットワークを安全に接続しましょう
- ユーザデータへのアクセスは文書化し監視しましょう。アクセスログに記録され、監査されていることを確認しましょう
- デバッグエンドポイントは ACL によって制限されていることを確認しましょう
- ユーザの入力をサニタイズしましょう。ペイロードサイズの制限もしましょう
- 特定のユーザにアクセス拒否できる仕組みを持ちましょう。他のユーザに影響与えずに悪用を阻止できることになります
- 内部的に負荷などの影響を起こす可能性がある外部エンドポイントは避けましょう
キャパシティプランニング
- サービスがどのように拡張して行くかを文書化してください （例：ユーザ数、受信ペイロードのサイズ、受信メッセージ数など）
- サービスのリソース要件を文書化してくさあい (例：VM インスタンス数、Spanner インスタンス数、GPU や TPU などの特殊なハードウェアなど)
- リソースの成約の文書化。（例：タイプ、リージョンなど）
- リソースのクォータ制限の文書化 （例：API を使って新インスタンス作る場合の GCE API のレートリミットなど）
- 可能な場合、パフォーマンス低下などを測定するために負荷テストなどを検討してください