検証した改善でフィードバックの循環を完結させる

完結させたい循環を定義する

ソフトウェアは、利用中に証拠を生み出します。エラー、遅延、サポート依頼、インシデント、保守での指摘、繰り返す手作業などです。完全なライフサイクルでは、その証拠をエンジニアリングの判断に戻します。

自己改善するソフトウェアとは、自動化が変更の発見、提案、実装、検証を支援することを意味する場合があります。モデルが自分自身を学習させることを、必ずしも意味しません。アプリケーションコード、設定、テスト、指示、ワークフロー、モデルのパラメーターのうち、何が変わるのかを明示してください。

Self-healingは、既知の稼働状態を復旧します。Self-improvementは、将来よりよい結果が得られるようにシステムを変えます。後者を主張するには、比較と、回帰を防ぐ仕組みが必要です。

一つの観測をライフサイクル全体で追う

以下は、エンジニアリングの方法として提案する手順です。いずれかの製品が、すべての段階を自律的に実行するという主張ではありません。

これらの成果物の間に、参照関係を残します。事後検証の対応項目が「監視を改善する」だけでは、検証が困難です。シグナル、担当者、しきい値、テスト済みの対応を定義すれば、完了を確認できます。

提案から独立した評価を保つ

エージェントは、パッチを作成し、テストを提案できます。それでも、そのテストが元の問題を検出できるかをチームが確認する必要があります。変更によって密かに弱められない、バージョン管理された評価セットを維持します。

架空のメモリリークでは、同等のワークロードと各バージョンを比較します。大規模なエクスポート、キャンセル、再試行、アクセス拒否のケースを含めます。顧客のレコードを露出させずに、関連するデータの形を表せる合成データを使います。

レコードが欠落する、認可を迂回する、許容コストを超える場合は、高速なエクスポートでも拒否します。最適化の前に、これらの制約を定義します。そうしないと、選んだメトリクスだけを改善し、サービスを悪化させることがあります。

エージェントの指示やモデルを変更する場合は、代表的なタスクと既知の失敗で振る舞いを評価します。以前のバージョンを利用可能な状態に保ちます。指示の更新は、基盤となるモデルがインシデントから学習した証拠ではありません。

リリースして結果を測定する

カナリアリリースは、限定された利用者に候補バージョンを適用します。候補版と対照群のシグナルを比較し、適用を広げる条件と停止する条件を定義します。トラフィックが少ない場合や、ワークロードが異なる場合は、比較しても結論が出ないことがあります。カナリアリリースのガイダンス。

架空のチームは、固定した合成ワークロードでベースラインを記録します。修正をテストし、承認された範囲でリリースして、比較可能な本番環境の期間を確認します。証拠が不十分なままなら、効果を宣言する代わりに、不確実性を記録します。

繰り返す手作業も測定します。自動化はtoilを減らせますが、保守と障害対応も必要です。結果を判断するときは、これらのコストを含めます。Toilのガイダンス。

使えるフィードバック記録を作る

演習では、次の項目を使ってください。観測内容とバージョン、ベースライン、提案された原因、受け入れ基準、回帰の確認、変更とレビュー、リリース範囲、測定結果、担当者、次のレビューです。

Taiga Maintainingは、リポジトリの指摘を是正作業につなげます。Initiativesは、意図した変更を計画とデリバリーにつなげます。これらは、証拠のつながりの一部を提供します。それでも、デプロイと運用上の結果は、サービス責任者が検証する必要があります。Maintaining、Initiatives。

成熟したソフトウェアファクトリーは、製品をまたいでこの作業をつなげます。自動化が進んでも、意思決定の権限と評価基準を明確に保ってください。最終的な証拠は、生成された変更の数の増加ではなく、検証によって確認されたサービスの改善です。