Sekarang di hype tema DevOps. Konveyor integrasi berkelanjutan dan pengiriman CI / CD dilaksanakan oleh semua orang yang merasa menyukainya. Tetapi sebagian besar tidak selalu memperhatikan untuk memastikan keandalan sistem informasi pada berbagai tahap CI / CD Pipeline. Dalam artikel ini, saya ingin berbicara tentang pengalaman saya dalam mengotomatisasi pemeriksaan kualitas perangkat lunak dan menerapkan skenario yang mungkin untuk "penyembuhan sendiri" nya.

Sumber

Saya bekerja sebagai seorang insinyur di departemen manajemen layanan TI di LANIT-Integration . Area inti saya adalah implementasi berbagai sistem untuk memantau kinerja dan ketersediaan aplikasi. Saya sering berkomunikasi dengan pelanggan TI dari segmen pasar yang berbeda tentang masalah topikal memantau kualitas layanan TI mereka. Tugas utama adalah untuk meminimalkan waktu siklus rilis dan meningkatkan frekuensi rilis mereka. Ini, tentu saja, semuanya baik: lebih banyak rilis - lebih banyak fitur baru - lebih banyak pengguna puas - lebih banyak keuntungan. Namun dalam kenyataannya, tidak selalu semuanya berjalan baik. Pada tingkat penyebaran yang sangat tinggi, pertanyaan segera muncul tentang kualitas rilis kami. Bahkan dengan pipa yang sepenuhnya otomatis, salah satu masalah terbesar adalah transfer layanan dari pengujian ke produksi, yang tidak memengaruhi waktu kerja dan interaksi pengguna dengan aplikasi.

Berdasarkan hasil dari berbagai percakapan dengan pelanggan, saya dapat mengatakan bahwa kontrol kualitas rilis, masalah keandalan aplikasi dan kemungkinan "penyembuhan sendiri" (misalnya, rollback ke versi stabil) pada berbagai tahapan pipa CI / CD adalah di antara topik yang paling menarik dan relevan.


Baru-baru ini, saya sendiri bekerja di sisi pelanggan - dalam layanan dukungan aplikasi perbankan online. Arsitektur aplikasi kami menggunakan sejumlah besar layanan microser yang ditulis sendiri. Yang paling menyedihkan adalah bahwa tidak semua pengembang mengatasi laju perkembangan yang tinggi, kualitas beberapa layanan mikro yang diderita, yang memunculkan julukan konyol bagi mereka dan pembuatnya. Ada cerita tentang bahan apa yang terbuat dari produk ini.

"Pernyataan masalah"

Frekuensi rilis yang tinggi dan sejumlah besar layanan-mikro membuatnya sulit untuk memahami aplikasi secara keseluruhan, baik pada tahap pengujian maupun pada tahap operasional. Perubahan terjadi secara konstan dan sangat sulit untuk mengendalikannya tanpa alat pemantauan yang baik. Seringkali setelah rilis malam di pagi hari, pengembang duduk di atas tong bubuk dan menunggu apa pun untuk istirahat, meskipun pada tahap pengujian semua cek berhasil.

Ada satu hal lagi. Pada tahap pengujian, operabilitas perangkat lunak diperiksa: implementasi fungsi utama aplikasi dan tidak adanya kesalahan. Estimasi kinerja kualitatif tidak ada atau tidak memperhitungkan semua aspek aplikasi dan lapisan integrasi. Beberapa metrik mungkin tidak diperiksa sama sekali. Akibatnya, ketika gangguan terjadi di lingkungan yang produktif, departemen dukungan teknis hanya mengetahui kapan pengguna nyata mulai mengeluh. Saya ingin meminimalkan dampak perangkat lunak berkualitas rendah pada pengguna akhir.

Salah satu solusinya adalah dengan menerapkan proses kontrol kualitas perangkat lunak pada berbagai tahapan CI / CD Pipeline, menambahkan berbagai skrip untuk memulihkan sistem jika terjadi kecelakaan. Juga ingat bahwa kita memiliki DevOps. Bisnis berharap untuk menerima produk baru secepat mungkin. Karenanya, semua cek dan skrip kami harus otomatis.

Tugas ini dibagi menjadi dua komponen:

• kontrol kualitas majelis pada tahap pengujian (untuk mengotomatisasi proses penangkapan majelis di bawah standar);
• kontrol kualitas perangkat lunak di lingkungan produksi (mekanisme deteksi masalah otomatis dan skenario yang memungkinkan untuk penyembuhan diri).

Alat untuk memantau dan mengumpulkan metrik

Untuk merealisasikan tugas-tugas yang ditetapkan, diperlukan suatu sistem pemantauan yang dapat mendeteksi masalah dan memindahkannya ke sistem otomasi pada berbagai tahap pipa CI / CD. Juga, poin positif adalah jika sistem ini memberikan metrik yang berguna untuk berbagai tim: pengembangan, pengujian, operasi. Dan cukup luar biasa, jika untuk bisnis.

Untuk mengumpulkan metrik, Anda dapat menggunakan kombinasi berbagai sistem (Prometheus, ELK Stack, Zabbix, dll.), Tetapi, menurut pendapat saya, solusi APM ( Pemantauan Kinerja Aplikasi ) paling cocok untuk tugas-tugas ini, yang dapat sangat menyederhanakan hidup Anda.

Sebagai bagian dari pekerjaan saya di layanan pendamping, saya mulai melakukan proyek serupa menggunakan solusi kelas Dynatrace APM. Sekarang, bekerja sebagai integrator, saya tahu pasar sistem pemantauan dengan cukup baik. Pendapat subjektif saya: Dynatrace paling cocok untuk tugas-tugas seperti itu.
Solusi Dynatrace memberikan tampilan horizontal setiap operasi pengguna dengan tingkat detail yang mendalam hingga ke tingkat eksekusi kode. Anda dapat melacak seluruh rantai interaksi antara berbagai layanan informasi: mulai dari aplikasi web dan mobile front-end, server aplikasi back-end, bus integrasi hingga panggilan khusus ke database.

Sumber Konstruksi otomatis semua ketergantungan antara komponen sistem

Sumber Deteksi otomatis dan pembangunan jalur untuk operasi layanan

Ingat juga bahwa kita perlu berintegrasi dengan berbagai alat otomasi. Di sini solusinya memiliki API praktis yang memungkinkan Anda mengirim dan menerima berbagai metrik dan acara.

Selanjutnya, kami akan beralih ke diskusi yang lebih terperinci tentang cara menyelesaikan tugas menggunakan sistem Dynatrace.

Tugas 1. Otomatisasi kontrol kualitas majelis pada tahap pengujian

Tugas pertama adalah menemukan masalah sedini mungkin pada tahap-tahap pipa pengiriman aplikasi. Hanya kode "baik" yang dapat mencapai lingkungan prod. Untuk melakukan ini, monitor tambahan harus disertakan dalam pipa Anda pada tahap pengujian untuk memverifikasi kualitas layanan Anda.



Mari kita lihat langkah-langkah cara mengimplementasikan ini dan mengotomatiskan proses ini:

Sumber

Gambar tersebut menunjukkan aliran langkah kontrol kualitas perangkat lunak otomatis:

1. penyebaran sistem pemantauan (pemasangan agen);
2. definisi peristiwa penilaian kualitas perangkat lunak Anda (metrik dan nilai ambang batas) dan transfernya ke sistem pemantauan;
3. pembangkitan beban dan uji kinerja;
4. mengumpulkan data kinerja dan ketersediaan dalam sistem pemantauan;
5. mentransfer data uji berdasarkan peristiwa penilaian kualitas perangkat lunak dari sistem pemantauan ke sistem CI / CD. Analisis perakitan otomatis.

Langkah 1. Menyebarkan sistem pemantauan

Anda harus menginstal agen terlebih dahulu di lingkungan pengujian Anda. Pada saat yang sama, solusi Dynatrace memiliki fitur yang bagus - menggunakan agen universal OneAgent, yang diinstal pada instance OS (Windows, Linux, AIX), secara otomatis mendeteksi layanan Anda dan mulai mengumpulkan data pemantauan pada mereka. Anda tidak perlu mengonfigurasi agen secara terpisah untuk setiap proses. Situasi serupa akan terjadi pada platform cloud dan container. Pada saat yang sama, Anda juga dapat mengotomatiskan pemasangan agen. Dynatrace sangat cocok dengan konsep "infrastruktur sebagai kode" ( Infrastruktur sebagai kode atau IaC ): ada skrip dan instruksi siap pakai untuk semua platform populer. Sematkan agen dalam konfigurasi layanan Anda, dan ketika Anda menyebarkannya, Anda segera mendapatkan layanan baru dengan agen yang sudah berjalan.

Langkah 2. Identifikasi peristiwa penilaian kualitas perangkat lunak Anda

Sekarang Anda perlu menentukan daftar layanan dan operasi bisnis. Penting untuk mempertimbangkan dengan tepat operasi-operasi pengguna yang penting bagi bisnis untuk layanan Anda. Di sini saya merekomendasikan konsultasi dengan analis bisnis dan sistem.

Selanjutnya, Anda perlu menentukan metrik mana yang ingin Anda sertakan dalam verifikasi untuk setiap level. Misalnya, bisa runtime (dengan pemisahan menurut rata-rata, median, persentil, dll.), Kesalahan (logis, layanan, infrastruktur, dll.) Dan berbagai metrik infrastruktur (tumpukan memori, pengumpul sampah, jumlah utas, dll.).

Untuk otomatisasi dan kemudahan penggunaan, tim DevOps memperkenalkan konsep "Pemantauan sebagai kode". Yang saya maksudkan adalah bahwa pengembang / tester dapat menulis file JSON sederhana yang mendefinisikan indikator kontrol kualitas perangkat lunak.

Mari kita lihat contoh file JSON tersebut. Objek dari Dynatrace API digunakan sebagai pasangan kunci / nilai (lihat Dynatrace API untuk deskripsi API ).

{    "timeseries": [    {      "timeseriesId": "service.ResponseTime",      "aggregation": "avg",      "tags": "Frontend",      "severe": 250000,      "warning": 1000000    },    {      "timeseriesId": "service.ResponseTime ",      "aggregation": "avg",      "tags": "Backend",      "severe": 4000000,      "warning": 8000000    },    {      "timeseriesId": "docker.Container.Cpu",      "aggregation": "avg",      "severe": 50,      "warning": 70    }  ] } 

File adalah array definisi deret waktu:

• timeseriesId - metrik diperiksa, misalnya, Waktu Respons, jumlah Kesalahan, Memori yang digunakan, dll.;
• agregasi - tingkat agregasi metrik, dalam kasus kami rata-rata, tetapi Anda dapat menggunakan apa pun yang Anda butuhkan (rata-rata, minimum, maks, jumlah, jumlah, persentil);
• tag - tag objek dalam sistem pemantauan, atau Anda dapat menentukan pengenal objek tertentu;
• parah dan peringatan - indikator ini menyesuaikan nilai ambang metrik kami, jika nilai pengujian melebihi ambang parah, maka perakitan kami ditandai sebagai tidak berhasil.

Gambar berikut ini menunjukkan contoh penggunaan trasholds tersebut.

Sumber

Langkah 3. Muat Generasi

Setelah kami menentukan tingkat kualitas layanan kami, perlu untuk menghasilkan beban uji. Anda dapat menggunakan salah satu alat pengujian yang nyaman bagi Anda, misalnya, Jmeter, Selenium, Neotys, Gatling, dll.

Sistem pemantauan Dynatrace memungkinkan Anda untuk menangkap berbagai metadata dari pengujian Anda dan mengenali pengujian mana yang terkait dengan siklus rilis dan layanan mana. Anda disarankan untuk menambahkan header tambahan ke permintaan HTTP pengujian.

Gambar berikut menunjukkan contoh di mana, menggunakan header X-Dynatrace-Test opsional, kami menandai bahwa tes ini mengacu pada pengujian operasi penambahan item ke troli.

Sumber

Ketika Anda menjalankan setiap tes beban, Anda mengirim informasi kontekstual tambahan ke Dynatrace menggunakan API acara dari server CI / CD. Dengan demikian, sistem dapat membedakan antara tes yang berbeda di antara mereka sendiri.

Sumber Acara di sistem pemantauan tentang peluncuran pengujian beban

Langkah 4-5. Kumpulkan data kinerja dan transfer data ke sistem CI / CD

Bersama dengan tes yang dihasilkan, sebuah peristiwa ditransmisikan ke sistem pemantauan tentang perlunya mengumpulkan data tentang pengecekan indikator kualitas layanan. File JSON kami juga ditunjukkan, di mana metrik kunci didefinisikan.

Peristiwa tentang perlunya memverifikasi kualitas perangkat lunak yang dihasilkan pada server CI / CD untuk dikirim ke sistem pemantauan

Dalam contoh kami, acara kontrol kualitas disebut perfSigDynatraceReport (Performance_Signature ) - ini adalah plug - in yang siap pakai untuk integrasi dengan Jenkins, yang dikembangkan oleh orang-orang dari T-Systems Multimedia Solutions. Setiap acara tentang peluncuran tes berisi informasi tentang layanan, nomor build, dan waktu tes. Plugin mengumpulkan nilai kinerja selama perakitan, mengevaluasi mereka dan membandingkan hasilnya dengan rakitan sebelumnya dan persyaratan non-fungsional.

Acara di sistem pemantauan tentang dimulainya kontrol kualitas perakitan. Sumber

Setelah tes selesai, semua metrik penilaian kualitas perangkat lunak ditransfer kembali ke sistem integrasi berkelanjutan, misalnya, Jenkins, yang menghasilkan laporan tentang hasilnya.

Hasil statistik perakitan di server CI / CD. Sumber

Untuk setiap unit, kami melihat statistik untuk setiap metrik yang kami atur selama seluruh tes. Kami juga melihat apakah ada pelanggaran pada nilai ambang tertentu (peringatan dan thrashold parah). Berdasarkan metrik agregat, seluruh unit ditandai sebagai stabil, tidak stabil, atau gagal. Selain itu, untuk kenyamanan, Anda dapat menambahkan indikator untuk membandingkan unit saat ini dengan yang sebelumnya dalam laporan.

Lihat statistik perakitan terperinci di server CI / CD. Sumber

Perbandingan rinci dari dua majelis

Jika perlu, Anda dapat pergi ke antarmuka Dynatrace dan di sana melihat lebih detail statistik untuk masing-masing majelis Anda dan membandingkannya satu sama lain.

Perbandingan statistik perakitan di Dynatrace. Sumber

Kesimpulan

Sebagai hasilnya, kami mendapatkan layanan “monitoring as a service”, terotomatisasi dalam pipa integrasi berkelanjutan. Pengembang atau penguji hanya perlu menentukan daftar metrik dalam file JSON, dan segala sesuatu lainnya terjadi secara otomatis. Kami mendapatkan kontrol kualitas rilis yang transparan: semua pemberitahuan tentang kinerja, konsumsi sumber daya, atau regresi arsitektur.

Tugas 2. Otomatisasi kontrol kualitas perangkat lunak dalam lingkungan produksi

Jadi, kami memecahkan masalah bagaimana mengotomatiskan proses pemantauan pada tahap pengujian di Pipeline. Dengan demikian, kami meminimalkan persentase rakitan berkualitas rendah yang mencapai lingkungan makanan.

Tetapi apa yang harus dilakukan jika perangkat lunak yang buruk masih sampai pada titik penjualan, baik, atau hanya sesuatu yang rusak. Untuk utopia, kami ingin memiliki mekanisme untuk mendeteksi masalah secara otomatis dan, jika mungkin, sistem itu sendiri akan mengembalikan kapasitas kerjanya, setidaknya di malam hari.

Untuk melakukan ini, kami, dengan analogi dengan bagian sebelumnya, memberikan pemeriksaan kualitas perangkat lunak otomatis di lingkungan produksi dan membuat skrip untuk penyembuhan sendiri dari sistem di bawahnya.


Perbaiki otomatis sebagai kode

Sebagian besar perusahaan telah memiliki basis pengetahuan yang terakumulasi pada berbagai jenis masalah umum dan daftar tindakan untuk memperbaikinya, misalnya, memulai kembali proses, membersihkan sumber daya, mengembalikan versi konfigurasi, mengembalikan perubahan konfigurasi yang salah, menambah atau mengurangi jumlah komponen dalam sebuah cluster, mengganti garis biru atau hijau dan lainnya

Terlepas dari kenyataan bahwa kasus penggunaan ini telah dikenal selama bertahun-tahun oleh banyak tim yang berkomunikasi dengan saya, hanya beberapa yang berpikir dan berinvestasi dalam otomasi mereka.

Jika Anda memikirkannya, maka dalam penerapan proses penyembuhan sendiri kesehatan aplikasi tidak ada yang super rumit, Anda perlu menyajikan skenario kerja admin Anda yang terkenal dalam bentuk skrip kode (konsep "koreksi otomatis sebagai kode") yang Anda tulis sebelumnya untuk setiap kasus spesifik. Skenario perbaikan otomatis harus mengatasi akar penyebab masalah. Anda mengatur sendiri tindakan respons insiden yang tepat.

Setiap metrik dari sistem pemantauan Anda dapat bertindak sebagai pemicu untuk menjalankan skrip, yang terpenting adalah bahwa metrik ini secara akurat menentukan bahwa semuanya buruk, karena saya tidak ingin mendapatkan hasil positif palsu di lingkungan yang produktif.

Anda dapat menggunakan sistem atau set sistem apa pun: Prometheus, ELK Stack, Zabbix, dll. Tetapi saya akan memberikan beberapa contoh berdasarkan solusi APM (Dynatrace akan kembali menjadi contoh), yang juga akan membantu membuat hidup Anda lebih mudah.

Pertama, ada segala sesuatu yang berkaitan dengan operabilitas dalam hal aplikasi. Solusi ini menyediakan ratusan metrik pada berbagai tingkatan yang dapat Anda gunakan sebagai pemicu:

• tingkat pengguna (browser, aplikasi seluler, perangkat IoT, perilaku pengguna, konversi, dll.);
• tingkat layanan dan operasi (kinerja, ketersediaan, kesalahan, dll.);
• tingkat infrastruktur aplikasi (metrik OS host, JMX, MQ, server web, dll.);
• tingkat platform (virtualisasi, cloud, wadah, dll.).

Tingkat pemantauan di Dynatrace. Sumber

Kedua, seperti yang saya katakan sebelumnya, Dynatrace memiliki API terbuka, yang membuatnya sangat mudah untuk mengintegrasikannya dengan berbagai sistem pihak ketiga. Misalnya, mengirim pemberitahuan ke sistem otomasi ketika parameter kontrol terlampaui.

Di bawah ini adalah contoh untuk berinteraksi dengan Ansible.

Sumber

Di bawah ini saya akan memberikan beberapa contoh otomatisasi mana yang dapat dilakukan. Ini hanya sebagian dari kasus-kasus ini, mendaftarkannya di lingkungan Anda hanya dapat dibatasi oleh imajinasi Anda dan kemampuan alat pemantauan Anda.

1. Penyebaran yang buruk - versi rollback

Bahkan jika kita semua menguji dengan sangat baik di lingkungan pengujian, masih ada kemungkinan bahwa rilis baru dapat membunuh aplikasi Anda di lingkungan prod. Faktor manusia yang sama belum dibatalkan.

Pada gambar berikut, kita melihat bahwa ada lonjakan tajam dalam waktu pelaksanaan operasi pada layanan. Awal lompatan ini bertepatan dengan waktu penerapan ke aplikasi. Kami mentransfer semua informasi ini sebagai peristiwa ke sistem otomasi. Jika kemampuan layanan tidak menormalkan setelah waktu yang ditentukan oleh kami berakhir, sebuah skrip secara otomatis dipanggil yang memutar kembali versi ke versi yang lama.

Degradasi kinerja setelah penerapan. Sumber

2. Memuat sumber daya di 100% - menambahkan node ke routing

Dalam contoh berikut, sistem pemantauan menentukan bahwa salah satu komponen memiliki utilisasi CPU 100%.

Pemanfaatan CPU 100%

Beberapa skenario berbeda dimungkinkan untuk acara ini. Sebagai contoh, sistem pemantauan juga memeriksa apakah kurangnya sumber daya dikaitkan dengan peningkatan beban pada layanan. Jika, ya, maka skrip dijalankan yang secara otomatis menambahkan node ke perutean, sehingga memulihkan sistem secara keseluruhan.

Penskalaan node setelah insiden

3. Kurangnya ruang hard drive - Pembersihan Disk

Saya pikir banyak dari proses ini sudah otomatis. Menggunakan APM, Anda juga dapat memantau ruang kosong pada subsistem disk. Dengan tidak adanya ruang atau operasi disk yang lambat, kami memanggil skrip untuk membersihkan atau menambah ruang.


Disk memuat 100%

4. Aktivitas pengguna rendah atau konversi rendah - beralih antara cabang biru dan hijau

Saya sering bertemu pelanggan menggunakan dua sirkuit (penyebaran biru-hijau) untuk aplikasi di lingkungan produksi. Ini memungkinkan Anda untuk dengan cepat berpindah antar cabang saat mengirimkan rilis baru. Seringkali setelah penyebaran, perubahan kardinal dapat terjadi yang tidak segera terlihat. Namun, penurunan kinerja dan ketersediaan mungkin tidak diamati. Untuk merespons dengan cepat perubahan tersebut, sebaiknya gunakan berbagai metrik yang mencerminkan perilaku pengguna (jumlah sesi dan tindakan pengguna, konversi, rasio pentalan). Gambar berikut ini menunjukkan contoh di mana ketika konversi turun, beralih di antara cabang perangkat lunak terjadi.

Penurunan konversi setelah beralih di antara cabang perangkat lunak. Sumber

Mekanisme penentuan masalah otomatis

Pada akhirnya saya akan memberikan satu contoh lagi, yang paling saya sukai Dynatrace.

Dalam bagian dari cerita saya tentang otomatisasi kontrol kualitas rakitan dalam lingkungan pengujian, kami menentukan semua nilai ambang batas dalam mode manual. Ini normal untuk lingkungan pengujian, tester itu sendiri menentukan indikator sebelum setiap tes, tergantung pada beban. Dalam lingkungan produksi, diinginkan bahwa masalah dideteksi secara otomatis, dengan mempertimbangkan berbagai mekanisme dasar.

Dynatrace memiliki alat kecerdasan buatan bawaan yang menarik, yang didasarkan pada mekanisme untuk menentukan metrik anomali (baselining) dan membuat peta interaksi antara semua komponen, membandingkan dan menghubungkan peristiwa di antara mereka, menentukan anomali dalam pekerjaan layanan Anda dan memberikan informasi terperinci tentang setiap masalah dan akar penyebab.

Dengan secara otomatis menganalisis dependensi antar komponen, Dynatrace menentukan tidak hanya apakah layanan bermasalah adalah penyebab utama, tetapi juga ketergantungannya pada layanan lain. Dalam contoh di bawah ini, Dynatrace secara otomatis memantau dan mengevaluasi kesehatan setiap layanan sebagai bagian dari transaksi, mengidentifikasi layanan Golang sebagai alasan utama.

Contoh menentukan akar penyebab kegagalan. Sumber

Gambar berikut menunjukkan proses pemantauan masalah dengan aplikasi Anda sejak awal insiden.

Visualisasi masalah yang muncul dengan tampilan semua komponen dan peristiwa pada mereka

Sistem pemantauan telah menyusun kronologi lengkap peristiwa tentang masalah tersebut. Di jendela di bawah timeline, kita melihat semua peristiwa utama pada masing-masing komponen. Berdasarkan peristiwa ini, Anda dapat menentukan prosedur untuk koreksi otomatis dalam bentuk skrip kode.

Selain itu, saya menyarankan Anda untuk mengintegrasikan sistem pemantauan dengan Service Desk atau pelacak bug. Jika masalah terjadi, pengembang dengan cepat menerima informasi lengkap untuk analisisnya di tingkat kode di lingkungan produksi.

Kesimpulan

Akibatnya, kami berakhir dengan pipa CI / CD dengan pemeriksaan kualitas perangkat lunak otomatis terintegrasi di Pipa. Kami meminimalkan jumlah rakitan berkualitas rendah, meningkatkan keandalan sistem secara keseluruhan, dan jika kami masih mengganggu kinerja sistem, kami meluncurkan mekanisme untuk memulihkannya.


Pasti sepadan dengan upaya untuk mengotomatiskan pemantauan kualitas perangkat lunak, ini tidak selalu merupakan proses yang cepat, tetapi seiring waktu akan membuahkan hasil. Saya merekomendasikan bahwa setelah menyelesaikan insiden baru di lingkungan prod, segera pikirkan monitor mana yang akan ditambahkan untuk memeriksa di lingkungan pengujian untuk menghindari mendapatkan build yang buruk di dalam prod, dan juga membuat skrip untuk secara otomatis memperbaiki masalah ini.

Saya harap teladan saya akan membantu Anda dalam usaha Anda. Juga menarik bagi saya untuk melihat contoh metrik yang digunakan untuk implementasi sistem penyembuhan diri.

Sumber