"Dan jika kamu tidak menembak, maka aku akan dimanjakan"
Sampai baru-baru ini, diyakini bahwa layanan harus bekerja. Mereka menggambar, membuat, menulis skrip - semuanya tampak baik-baik saja, Anda dapat memasukkannya ke prod.
Tetapi pesaing tidak tertidur, jadi balapan dimulai tidak hanya untuk fitur baru, tetapi juga untuk kecepatan. Pembekuan aplikasi atau respons server lama (belum lagi kesalahan pop-up ke-500) merusak kesan layanan dan memaksa pengguna untuk meninggalkan tempat lain. Tentunya, semua orang menghadapi situasi ketika, alih-alih membeli tiket pesawat, kereta api atau konser, "Kesalahan server internal" ditampilkan di layar, dan Anda sangat marah karena merusak monitor.
Saya Viktor Bodrov, saya bekerja di Yandex.Money di tim riset kinerja dan saya ingin berbicara tentang bagaimana mempelajari produktivitas secara langsung pada produksi.
Setiap menit downtime adalah bencana bagi perusahaan, terutama bagi mereka yang terlibat dalam transaksi keuangan, seperti transfer dan pembayaran, pembayaran barang di toko. Setiap pembayaran gantung tidak hanya kerugian moneter, tetapi juga kerugian reputasi. Dalam kondisi seperti itu, uptime yang tinggi diperlukan, untuk itu perlu untuk menjaga denyut nadi sistem pembayaran dan terus-menerus memantau semua indikatornya, dengan memperhatikan kinerja.
Mengapa merisetnya?
Pertama, mengetahui kinerja layanan Anda sendiri membantu Anda mempersiapkan peluncuran fitur baru, berbagai promosi dan penjualan. Pengetahuan tentang indikator yang dapat diandalkan akan membantu pada waktu yang tepat untuk memenuhi masuknya pengguna baru tidak dengan gerbang kecil dengan pintu putar, tetapi dengan pintu depan terbuka lebar dan lengan terbuka.
Kedua, layanan yang baik harus mengetahui batas kinerjanya setiap saat, jadi pengukuran harus teratur. Jika Anda cukup sering melakukan ini, menjaga relevansi data, maka jangan lewatkan degradasi dalam layanan Anda dan Anda dapat dengan cepat mengembalikan indikator yang diperlukan.
Ketiga, dengan mengandalkan data kinerja terbaru, lebih mudah bagi bisnis untuk merencanakan pengembangan layanan dan memilih arah pertumbuhan.
Bagi mereka yang bingung dengan masalah seperti itu untuk pertama kalinya, muncul pertanyaan: di mana dan bagaimana mengukur produktivitas? Seringkali, bangku digunakan untuk eksperimen semacam itu. Di perusahaan individu, ada stand khusus untuk riset kinerja. Jika Anda memilikinya - hebat! Jika 1 in 1 sesuai dengan produk, maka semuanya baik-baik saja dengan Anda. Tetapi paling sering itu sangat mahal untuk mempertahankan pendirian yang sepenuhnya cocok dengan produk. Bagaimana menjadi? Ternyata satu - satunya tempat yang sepenuhnya sesuai dengan produk adalah produk itu sendiri?
Bagi banyak orang, proposal untuk mengukur dan memverifikasi sesuatu secara langsung pada prod itu terdengar sesat. Jangan khawatir jika semuanya dilakukan dengan hati-hati, tidak ada hal buruk yang akan terjadi. Misalnya, kami melakukan pra-perhitungan risiko yang mungkin terjadi dan menentukan apa yang mungkin dialami sistem kami dari percobaan. Bersamaan dengan ini, kami merencanakan cara mengurangi bahaya, dan terus-menerus memantau status sistem.
Penelitian tentang prod tidak membatalkan penggunaan dudukan. Ini dapat melakukan pemeriksaan rilis dan percobaan khusus untuk mempelajari kinerja layanan microsoft, termasuk mereka secara individu atau dalam berbagai kombinasi.
Keuntungan utama dan tak terbantahkan dari hasil yang diperoleh di prod - mereka adalah yang paling jujur dari semua opsi dan sedekat mungkin dengan pemrosesan lalu lintas pengguna yang sebenarnya. Tidak peduli seberapa dekat dudukannya dengan produk dalam hal karakteristik - tidak akan dapat menangkapnya, seperti kura-kura Achilles. Saat meneliti tentang prod, Anda akan menggunakan database yang sama dengan pengguna sungguhan, jaringan yang sama, lingkungan yang sama. Tidak perlu membangun apa pun, semuanya sudah dibangun sebelum Anda dan berfungsi dengan baik.
Data percobaan semacam itu akan menarik bagi semua insinyur, terlepas dari peran yang diberikan kepada mereka: pengembang, penguji, admin. Indikator kinerja yang dijamin juga akan menarik minat bisnis - bagi pelanggan potensial mereka akan menjadi iklan layanan yang meyakinkan.
Pemilihan skenario dan pola aliran beban
Untuk pengaturan percobaan yang aman dan tepat, beberapa langkah wajib harus diselesaikan.
Pemilihan skenario
Langkah pertama, yang paling penting, adalah memilih skenario yang sedang dipelajari. Ini bisa berupa permintaan tunggal (misalnya, memeriksa saldo), atau skenario dengan logika kompleks, di mana setiap permintaan berikutnya tergantung pada hasil yang sebelumnya (pembayaran untuk barang di toko, transfer dari dompet ke dompet). Kami secara teratur mengambil daftar semua proses bisnis yang ada dalam sistem. Kami memiliki lebih dari 400 proses seperti itu. Berdasarkan tujuan bisnis, kami akan mengoordinasikan prioritas skenario.
Skenario apa yang harus dimasukkan dalam kelompok prioritas?
- Mereka yang lonjakan aktivitas pengguna diharapkan dalam waktu dekat.
- Yang ada pembatasan ketat yang konstan (karena berbagai alasan) yang tidak memungkinkan Anda untuk jatuh di bawah SLA.
Dengan demikian, dimungkinkan untuk membuat kumpulan skenario prioritas untuk pemeriksaan rutin pada prod. Di perusahaan kami, kami melakukan penembakan setidaknya seperempat sekali.
Serangkaian teknik dan alat dipilih tergantung pada logika skrip. Dalam kasus kami, skenario prioritas memiliki logika bercabang. Misalnya, saat melakukan pembayaran dengan kartu, berbagai pemeriksaan dilakukan, tergantung pada skrip mana yang berjalan di cabang sendiri, jadi kami menggunakan JMeter untuk mengimplementasikannya. Sangat nyaman hanya untuk skenario kompleks seperti itu, di mana setiap permintaan berikutnya tergantung pada hasil dari yang sebelumnya. Jika Anda perlu memotret satu permintaan, maka saya sarankan menggunakan Phantom berkinerja tinggi.
Untuk meneliti skenario pengguna, pengguna khusus mungkin diperlukan, atas nama permintaan yang akan dibuat. Jika Anda menggunakan satu pengguna atau sejumlah kecil dari mereka, Anda mungkin mengalami caching data, yang akan mendistorsi hasil. Semakin banyak pengguna, semakin akurat data penelitian.
Muat sirkuit
Pada langkah kedua, kami memilih sirkuit umpan intensitas input.
Misalnya, sebelum penjualan, kami menentukan apa saja cara utama pengguna akan membayar. Untuk menyetel dan melacak kemacetan, kami melakukan penembakan pada jenis pembayaran tertentu. Sebagai aturan, aktivitas pengguna selama berbagai promosi cenderung mendukung satu atau skenario lainnya. Dengan memeriksanya, Anda mendapatkan gambaran yang jelas tentang perilakunya di bawah beban.
Tetapi bisnis juga mungkin tertarik pada gambaran kinerja secara keseluruhan. Untuk kasus ini, Anda dapat menggabungkan skenario bisnis paling populer secara proporsional dengan penggunaannya oleh pengguna nyata, dan mengaktifkan beban kumulatif. Perlu dipertimbangkan bahwa dalam hal ini kesulitan mungkin timbul dengan penilaian kuantitatif. Alih-alih satu nomor kinerja tertentu, Anda akan mendapatkan seri angka, yang, pada gilirannya, dapat bervariasi tergantung pada proporsi skenario tertentu dalam aliran umum.
Suplai intensitas juga bisa berbeda. Saya akan fokus pada dua profil paling umum. Ini adalah tes dengan aliran yang secara linear (atau bertahap) meningkatkan aliran intensitas dan uji stabilitas, di mana operasi jangka panjang dari layanan diperiksa di bawah aliran intensitas yang besar dan stabil. Opsi kedua membutuhkan waktu penelitian yang lama, yang tidak selalu memungkinkan pada lingkungan pertempuran, di samping itu, tingkat intensitas yang disediakan harus sudah diketahui untuk itu.
Sumbu X - waktu, Sumbu Y - intensitas pemuatan (permintaan per detik)
Ada baiknya ketika ada SLA tertentu atas dasar di mana Anda dapat melakukan pemeriksaan dengan memantau kinerja, waktu respons dan memantau perilaku komponen. Situasi yang lebih umum adalah ketika tingkat kinerja tidak diketahui dan Anda perlu menentukannya. Untuk melakukan ini, kami menggunakan opsi pertama - pengukuran dengan meningkatnya intensitas yang disediakan. Kami mengaktifkan aliran input, meningkatkannya secara linear atau bertahap, kami melihat perilaku layanan. Beban yang diterapkan secara linear dapat lebih akurat melacak titik jenuh dan titik kerusakan. Ini dijelaskan lebih rinci dalam artikel kami . Tetapi intensitas yang disediakan secara bertahap menggabungkan pengujian stabilitas yang kecil, terutama jika langkah-langkahnya lama. Tidak disarankan untuk segera menerapkan aliran beban besar ke input, lebih baik untuk "menghangatkan" layanan, secara bertahap meningkatkan aliran input.
Anda juga dapat melakukan serangkaian dua percobaan. Pertama-tama ukur titik jenuh dengan beban dan henti yang diterapkan secara linear. Anda tidak harus terus memberi makan aliran lebih jauh ke gangguan, itu masih merupakan dorongan, bukan tegakan. Percobaan kedua adalah untuk melihat perilaku layanan di bawah beban langkah dengan memilih beberapa langkah di dekat titik saturasi. Dan kemudian lakukan uji stabilitas sejauh waktu memungkinkan, pilih beban 15-20% di bawah titik jenuh (atau kerusakan jika Anda tiba-tiba memilikinya sebelum jenuh). Mendaki lebih tinggi itu berbahaya.
Pengaturan waktu
Selanjutnya, Anda harus menentukan waktu percobaan. Salah satu kondisi paling penting untuk melakukan pengukuran kinerja pada prod adalah keamanan untuk semua pengguna nyata. Sangat jarang ada kesempatan untuk menghentikan layanan untuk sementara waktu untuk pencegahan dan dengan tenang membombardirnya. Sebagai aturan, layanan online disetel untuk berfungsi 24/7, jadi Anda harus menyesuaikan dengan mode penggunaan layanan.
Adalah logis bahwa semakin tinggi aktivitas pengguna yang sebenarnya, semakin banyak risiko bahwa pengambilan gambar dapat menyebabkan downtime dan kerugian finansial. Di sisi lain, semakin sedikit lalu lintas pengguna, semakin sedikit kesalahan pengukuran. Oleh karena itu, untuk meminimalkan dampak percobaan, disarankan agar dilakukan dalam periode aktivitas pengguna yang berkurang.
Seperti yang ditunjukkan oleh praktik, aktivitas minimum pengguna kami jatuh pada periode dari dua hingga tujuh di pagi hari. Tentu saja, setiap layanan memiliki karakteristik dan pemirsanya sendiri, jadi kami menentukan waktu pemotretan dengan memantau perilaku pengguna. Tidak selalu mungkin untuk mengatur eksperimen dalam periode optimal yang dipilih. Untuk menembakkan prod, terutama pada tahap awal koneksi mereka, kontrol yang lebih tinggi diperlukan. Ini akan menyebabkan kesulitan, karena kolega Anda juga manusia dan mungkin tidak selalu pergi bekerja di malam hari. Situasi ini akan membutuhkan kompromi. Anda harus memilih waktu yang cocok untuk semua orang dan pada saat yang sama memenuhi kondisi aktivitas pengguna yang rendah.
Kesulitan dalam bekerja dengan rekanan
Jika layanan terkait tidak hanya dengan perhitungan internal, tetapi juga interaksi dengan layanan pihak ketiga (rekanan), Anda perlu memilih bagaimana Anda akan melakukan pemecatan Anda: bersama dengan rekanan atau sebaliknya menggunakan layanan rintisan. Tentu, jika Anda berencana untuk menembak di server rekanan, Anda harus menyetujui semuanya terlebih dahulu. Ini akan sangat mempersulit persiapan untuk menembak, tetapi akan menambah nilai tambah pada kebenaran hasil yang diperoleh sebagai hasilnya.
Dan sebaliknya: jika Anda mengganti layanan rekanan dengan colokan, persiapan untuk pemotretan akan sangat disederhanakan, tetapi kejujuran hasilnya akan berkurang. Harus diingat bahwa rintisan harus meniru perilaku pihak lawan sebanyak mungkin, dan tidak hanya memberi 200 OK.
Counterparties sendiri berbeda. Beberapa mudah pergi ke pemeriksaan bersama, sementara yang lain menjalankan setiap langkah melalui banyak contoh. Menentukan waktu percobaan juga dapat menyebabkan kontroversi. Sebagai contoh, beberapa kantor negara setuju untuk bekerja hanya dari 9 hingga 18 jam.
Memeriksa akses dan koordinasi dengan Dewan Keamanan, departemen keuangan, admin
Pada bagian ini, kami akan fokus pada akses dan persetujuan dengan semua orang yang bertanggung jawab - layanan keamanan, departemen keuangan dan administrator sistem.
Anda perlu memeriksa akses yang diperlukan . Pastikan tidak ada yang akan mengganggu penelitian dan, jika perlu, memesan akses dari admin jaringan, baik dari Anda sendiri maupun rekanan, jika Anda bekerja dengan mereka. Admin jaringan akan membantu menyeimbangkan pengaturan. Kami pernah memiliki saklar penyeimbang dari round-robin ke ip-hash. Akibatnya, semua kueri kami jatuh di bagian depan yang sama, dipilih oleh algoritma balancing baru.
Setelah mendapatkan akses, Anda perlu men-debug dan memeriksa skrip pada aliran unit terkecil.
Langkah selanjutnya adalah persetujuan . Pertama-tama, hubungi layanan keamanan agar percobaan Anda tidak dihentikan saat lepas landas karena "aktivitas mencurigakan". Untuk menilai semua risiko yang mungkin dari Dewan Keamanan, diperlukan rencana penembakan yang terperinci - siapa, apa, dan dalam jumlah apa saja yang terlibat di dalamnya.
Selanjutnya, Anda perlu mengoordinasikan rencana pemecatan dengan departemen keuangan dan komersial. Jika layanan dikaitkan dengan kegiatan keuangan, maka koordinasi dengan departemen keuangan dan akuntansi akan diperlukan. Aktivitas keuangan tambahan apa pun dapat memengaruhi laporan keuangan atau bahkan menyebabkan kegagalan fungsi dalam pembentukan berbagai ringkasan posting. Ini harus dihindari, jadi ada baiknya untuk memperingatkan kolega, setelah mengerjakan konfigurasi percobaan yang optimal.
Jika Anda memiliki departemen statistik yang mengumpulkan informasi tentang pengoperasian layanan, maka Anda perlu mengoordinasikan penembakan dengan mereka. Faktanya adalah bahwa aliran beban akan menyebabkan gelombang statistik tambahan. Setuju apakah mereka akan mempertimbangkan tes dalam laporan mereka atau tidak. Jika tidak, maka putuskan bagaimana data pengguna nyata akan dipisahkan dari yang diuji.
Saat merencanakan, Anda juga perlu mengoordinasikan tanggal dan waktu tes dengan departemen komersial, apakah mereka memiliki iklan atau promosi yang direncanakan untuk saat ini atau di sekitarnya. Jangan lupa untuk memberi tahu pemimpin tim tentang semua kegiatan yang direncanakan dan tidak terencana pada prod. Secara alami, Anda perlu memperingatkan dan menyetujui admin, karena selama penembakan partisipasi mereka mungkin diperlukan. Selain itu, admin dalam kursus tentang semua tindakan pada prod. Mungkin tepat pada waktu yang Anda pilih, pergantian pusat data, penggantian server, atau pekerjaan lain direncanakan.
Penembakan dan analisis hasil
Akhirnya, kami membahas melakukan penembakan dengan pemantauan. Kami menentukan ke mana harus mencari selama percobaan, dalam kondisi apa yang harus dihentikan, ke sensor mana yang merespons? Ini harus dilakukan "darat", sebelum memulai pemotretan.
Ada beberapa alasan untuk berhenti.
1) Pada sinyal dari pemantauan. Dalam hal ini, tidak masalah apakah fungsionalitas yang terlibat dalam eksperimen terputus atau jika terjadi keadaan darurat di ujung lain layanan. Anda perlu menghentikan tes dan memahami alasannya, karena kelancaran pengoperasian layanan adalah salah satu prioritas utama.
2) Dengan pertumbuhan kesalahan jaringan atau HTTP. Ini adalah situasi darurat yang membutuhkan intervensi.
3) Jika saturasi tercapai, kinerja tidak lagi tumbuh, tetapi waktu respons meningkat. Tidak perlu menunggu kerusakan dan menempatkan dorongan. Hasil untuk analisis sudah ada, Anda dapat dengan aman menghentikan percobaan.
Setelah percobaan, Anda dapat memahami bahwa tidak ada cukup log dan hasil dan Anda perlu mengulangi percobaan dengan logging-debug diaktifkan. Ini akan membuat log dan penulisan ke disk lebih berat, tetapi sekarang Anda tahu tingkat beban yang diperlukan, yang berarti bahwa alih-alih tes panjang, Anda dapat melakukannya lebih pendek.
Analisis Hasil
Pada akhirnya, tetap menganalisis hasil dan menyediakan data yang diperoleh pihak yang berkepentingan. Anda dapat mulai melakukan ini selama percobaan. Kami menggunakan bundel Zabbix dan Elastic dengan Grafana dan Kibana untuk analisis. Kami memantau karakteristik waktu semua panggilan eksternal dan internal yang terlibat dalam percobaan kami, kami memantau kumpulan konektor, antrian, dan monitor basis data. Untuk pelacakan metrik dari sisi generator lalu lintas online - layanan Yandex Lunapark (ada analog terbuka - overload.yandex.net).
Presentasi hasil akan bervariasi tergantung pada siapa yang membutuhkannya. Untuk pengembangan, admin dan penguji memerlukan laporan terperinci dengan metrik, grafik, log, stacktrace yang akurat. Untuk bisnis, prakiraan hasil dan pengembangan adalah penting. Dalam hal ini, konkret dan penekanan angka lebih baik dan lebih visual. Untuk melakukan ini, Anda dapat menggunakan prinsip lampu lalu lintas. Zona merah buruk, sangat mendesak untuk dioptimalkan. Kuning - kami melihat penurunan indikator, Anda harus memperhatikan ini. Hijau - semuanya OK, teruskan. Pandangan yang jelas dan dapat diakses dari hasil penelitian akan membantu menghilangkan pertanyaan tentang pentingnya dan kegunaan pengukuran kinerja.
Penelitian yang berhasil, dan ingat keamanan pengguna!