Tutup siklus umpan balik dengan perbaikan yang terverifikasi

Tentukan siklus umpan balik yang ingin ditutup

Perangkat lunak menghasilkan bukti selama digunakan: error, keterlambatan, permintaan dukungan, insiden, temuan pemeliharaan, dan pekerjaan manual berulang. Siklus hidup yang lengkap membawa bukti tersebut kembali ke keputusan rekayasa.

Perangkat lunak yang memperbaiki diri dapat berarti bahwa otomasi membantu menemukan, mengusulkan, menerapkan, dan memverifikasi perubahan. Ini tidak selalu berarti model melatih dirinya sendiri. Nyatakan bagian yang berubah: kode aplikasi, konfigurasi, pengujian, instruksi, alur kerja, atau parameter model.

Self-healing memulihkan kondisi operasi yang sudah diketahui. Self-improvement mengubah sistem agar menghasilkan hasil yang lebih baik di masa depan. Klaim kedua memerlukan perbandingan dan perlindungan terhadap regresi.

Ikuti satu pengamatan sepanjang siklus hidup

Urutan berikut adalah usulan metode rekayasa. Urutan ini tidak menyatakan bahwa suatu produk menjalankan setiap langkah secara otonom.

Pertahankan hubungan antara hasil-hasil tersebut. Tindakan setelah postmortem yang hanya menyatakan “perbaiki pemantauan” sulit diverifikasi. Sinyal, penanggung jawab, ambang batas, dan respons teruji yang jelas membuat penyelesaian dapat diamati.

Jaga evaluasi tetap independen dari usulan

Agen dapat membuat patch dan mengusulkan pengujian. Tim tetap harus memeriksa apakah pengujian itu mendeteksi masalah awal. Simpan kumpulan evaluasi berversi yang tidak dapat diam-diam dilemahkan oleh perubahan.

Untuk kebocoran memori fiktif ini, bandingkan workload dan versi yang setara. Sertakan ekspor besar, pembatalan, percobaan ulang, dan kasus penolakan akses. Gunakan data sintetis yang mewakili bentuk data terkait tanpa memaparkan data pelanggan.

Tolak ekspor yang lebih cepat jika menghilangkan data, melewati otorisasi, atau melampaui biaya yang diizinkan. Tentukan batasan ini sebelum optimasi. Jika tidak, sistem dapat memperbaiki metrik pilihan sambil memperburuk layanan.

Jika Anda mengubah instruksi atau model agen, evaluasi perilakunya pada tugas representatif dan kegagalan yang diketahui. Pastikan versi sebelumnya tetap tersedia. Pembaruan instruksi tidak membuktikan bahwa model yang mendasarinya belajar dari suatu insiden.

Rilis dan ukur hasilnya

Rilis canary memaparkan versi kandidat kepada kelompok pengguna terbatas. Bandingkan sinyal kandidat dan kelompok kontrol, lalu tentukan kapan paparan diperluas atau dihentikan. Trafik yang sedikit atau workload yang berbeda dapat membuat perbandingan tidak menghasilkan kesimpulan. Panduan canary.

Tim fiktif mencatat kondisi awal pembanding dari workload sintetis tetap. Tim menguji perbaikan, merilis dalam batas yang disetujui, dan memeriksa periode produksi yang dapat dibandingkan. Jika bukti masih belum cukup, tim mencatat ketidakpastian dan tidak menyatakan peningkatan.

Ukur pula pekerjaan manual berulang. Otomasi dapat mengurangi toil, tetapi juga memerlukan pemeliharaan dan penanganan kegagalan. Sertakan biaya ini saat menilai hasil. Panduan toil.

Buat catatan umpan balik yang dapat digunakan

Gunakan kolom berikut untuk latihan: pengamatan dan versi; kondisi awal pembanding; dugaan penyebab; kriteria penerimaan; pemeriksaan regresi; perubahan dan peninjauan; batas rilis; hasil terukur; penanggung jawab dan peninjauan berikutnya.

Taiga Maintaining menghubungkan temuan repositori dengan pekerjaan perbaikan. Initiatives menghubungkan perubahan yang diinginkan dengan perencanaan dan pengiriman perangkat lunak. Keduanya menyediakan bagian dari rantai bukti. Penanggung jawab layanan tetap harus memverifikasi deployment dan hasil operasional. Maintaining, Initiatives.

Software factory yang matang menghubungkan pekerjaan ini lintas produk. Pastikan kewenangan keputusan dan kriteria evaluasi tetap terlihat ketika otomasi bertambah. Bukti akhirnya adalah layanan yang terbukti lebih baik, bukan jumlah perubahan yang dihasilkan lebih banyak.