タグ付けされた質問 「post-mortem」

ApproximateNumberOfMessagesVisibleCloudWatchメトリックスのスケーリングポリシーを使用した一連のSQSキュー処理ジョブを担当しています。これらのジョブは、さまざまな理由で送信されたメッセージの量に追いつくことができません。 サービスの低下により、処理可能なメッセージの容量が減少します。 AutoScaling キューの深さが上昇し続けている間に最大制限に達しました。 S3の停止AutoScalingは、キュー処理ジョブが需要に対応するために使用する他の依存AWSサービス（サービス）に影響します。 技術チーム以外のチームメンバーと停止について話し合うとき、顧客から見える品質低下につながる可能性のあるキュー処理の特定の遅延を伝えたいと思います。SQSキューでこれを行うにはどうすればよいですか？

13 amazon-web-services  amazon-sqs  amazon-cloudwatch  post-mortem 

停止しているコンテナや、起動後に非常に速く停止して停止するコンテナを調査する必要がある場合があります。 docker exec -ti <id> bash 実行中のコンテナでのみ機能し、終了すると、bashプロンプトも終了します。 ではdocker start、あなたは別のコマンドを供給することができない、とコンテナが突然再び死ぬ場合は、コンテナに入ると、あなたの調査を行うのに十分な時間がありません。 我々は行うことができdocker commit、その後、docker run別のコマンドを使用して新しいイメージではなく、他の選択肢がある場合、私は思ったんだけど。 注：docker logs印刷されたアプリをstdout / stderrに返すだけです。それは問題が何であったかを理解するのに十分ではないかもしれません。

13 docker  containers  post-mortem 

不変サーバーパターンは、デプロイメントの再現性を優先するデプロイメントの分野です。これは、「一度デプロイされたサーバーは決して変更されず、単に新しい更新されたインスタンスに置き換えられる」という特徴があり、この規律を実装するにはサーバーのデプロイメントの自動化が必要です。この自動化には多くの運用上の利点があります。最も重要なものの1つは、インフラストラクチャ内の障害のあるインスタンスを迅速かつ確実に交換できるようにすることです。この自動化は、サーバーの展開がバージョン管理されたソフトウェアアーティファクトによって記述され、反復的な改善の対象となることも意味します。 この分野の実装の一般的な側面は、サーバーが起動された後のリモートアクセスメソッドの削除です（特にSSHアクセスの削除）。リモートアクセスを削除することで、サーバーの構成を、展開の自動化によって準備された構成と確実に一致させることができます。 ただし、事後分析でソフトウェア障害の原因を調査する場合、構造化された監視に依存するだけでは必ずしも十分ではなく、マシンへのリモートアクセスが必要になる場合があります。サーバーの監視がすべての障害の原因を網羅していない、またはサーバーの障害自体によって監視が損なわれる可能性があるのは一般的な実際の状況です。 事後分析を実行する機能を失うことなく、不変サーバーパターンを実装する方法は？

12 immutable-servers  post-mortem