Bagaimana e-commerce bertahan dalam promosi skala besar. Bersiap untuk beban puncak di web [Bagian 2]

Halo, Habr!
Seminggu yang lalu ada sebuah artikel di mana saya memulai percakapan tentang bagaimana menyiapkan proyek e-commerce untuk pertumbuhan lalu lintas yang eksplosif dan kesenangan lain dari promosi skala besar.
Kami telah menemukan detail teknis utama, sekarang kami akan memperhatikan masalah administrasi dan mengoptimalkan proses dukungan selama beban puncak:

• apa yang membuat situs tidak stabil dan mengapa cloud bukan obat mujarab;
  
• parameter bisnis apa yang perlu dipantau untuk mendeteksi masalah sebelum menimbulkan kerugian yang signifikan;
  
• bagaimana cara mengarahkan insiden dari peristiwa ke solusi tanpa kekacauan dan melokalisasi kegagalan.
  

Dan banyak lagi - Saya meminta semua orang untuk memotong!

Dalam pengalaman saya, sakit kepala terbesar dalam mempersiapkan aksi skala besar adalah tekanan administratif yang kuat. Bisnis, yang sampai saat itu sangat tenang, tiba-tiba memiliki keinginan bahwa setiap orang harus berada di sungai, meniup debu dari situs, dan seterusnya, "Tuhan melarang apa yang terjadi, kita akan didenda." Mari kita coba untuk memuaskan hasrat yang umumnya sehat ini. Kita akan membicarakan ini pada contoh Black Friday, karena ini adalah contoh yang paling mencolok dari peningkatan tajam dalam beban di situs.
Dan kita akan mulai dengan pertanyaan mendasar: apa sebenarnya penyebab dari operasi situs kita yang tidak stabil?

Apa yang membuat situs tidak stabil

Waktunya telah tiba untuk melakukan apa yang telah Anda tunda sejak lama. Untuk memahami faktor-faktor apa yang membuat situs kurang stabil, angkat dan analisis riwayat masalah. Jangan katakan bahwa Anda tidak memilikinya.

Atas Anda akan memiliki plus atau minus alasan berikut:

1. Lepaskan crash terkait.
   
2. Admin mengacaukan - memperbaiki satu, tetapi yang lain rusak. Sayangnya, hamparan seperti itu sering disembunyikan dan tidak membuat sejarah.
   
3. Merusak bisnis - dengan ceroboh meluncurkan aksi, menghapus sesuatu, dll.
   
4. Layanan afiliasi yang rusak.
   
5. Perangkat lunak "Sedih". Paling sering ini terjadi karena paragraf. 1 dan 2.
   
6. Kerusakan fisik.
   
7. Masalah lainnya.
   

Tentu saja, semua situasi berbeda, dan "peringkat" Anda mungkin sedikit berbeda. Tetapi masalah yang terkait dengan perubahan pada situs dan faktor manusia, serta buah dari cinta bersama mereka - pelepasan atau upaya untuk mengoptimalkan sesuatu - masih akan memimpin.

Untuk memberantas masalah ini sehingga pada upaya pertama untuk membuat perubahan yang diperlukan dan tidak merusak apa yang berfungsi dengan baik, adalah tugas yang banyak salinannya telah rusak. Dan kami memiliki waktu yang sangat sedikit, hanya sekitar empat bulan. Untungnya, ini dapat ditangani secara lokal. Untuk melakukan ini, ikuti beberapa aturan sederhana:

1. Bekerja - jangan menyentuh.

Selesaikan semua pekerjaan yang direncanakan sedini mungkin - dalam beberapa minggu, dalam sebulan. Seberapa dini menangani perbaikan akan memberi tahu riwayat kejadian Anda. Ini menunjukkan berapa lama masalah utama berlangsung. Setelah itu, jangan menyentuh situs dan infrastruktur produk sampai beban telah lewat.

2. Jika Anda masih harus masuk ke produktif untuk perbaikan mendesak - tes.

Secara teratur, tanpa lelah, bahkan perubahan terkecil dan kecil. Pertama, dalam lingkungan pengujian, termasuk di bawah beban, dan baru kemudian mentransfernya ke prod. Dan lagi, uji dan periksa kembali parameter kunci situs. Lebih baik melakukan pekerjaan di malam hari, ketika bebannya minimal, karena Anda harus punya waktu untuk menyelamatkan situasi jika terjadi kesalahan. Pengujian yang baik adalah sains, tetapi pengujian yang cerdas saja lebih baik daripada tidak memilikinya. Yang utama adalah jangan mengandalkan "mungkin".

Membekukan perubahan selama beban tinggi adalah satu-satunya alat yang dapat diandalkan.

Apa yang harus dilakukan dengan layanan afiliasi, kami telah membahas di artikel sebelumnya. Singkatnya - putuskan tanpa ampun untuk masalah. Paling sering, banyak pengguna layanan segera mengalami masalah, dan menghubungi dukungan teknis adalah tindakan yang kurang efektif. Surat-surat Anda tidak akan membantu mereka memperbaiki lebih cepat, pada jam-jam seperti itu departemen TI dari layanan panas tanpa mereka.

Namun, jika Anda tidak melaporkan masalah dan tidak mendapatkan nomor insiden pada saat dimulainya, Anda kemungkinan besar tidak akan dapat membebankan biaya penalti kepada layanan karena melanggar SLA.

Sedikit tentang keandalan

Sebagai bagian dari persiapan, Anda perlu mengubah semua perangkat keras dan layanan cluster yang gagal. Lebih lanjut tentang ini di salah satu artikel saya sebelumnya.

Saya ingin menarik perhatian Anda ke kesalahpahaman populer berikut: tampaknya banyak yang mentransfer situs dari servernya ke cloud segera memberi +100 keandalan. Sayangnya, hanya +20.

Untuk meningkatkan toleransi kesalahan dari server virtual, cloud komersial hanya mengotomatisasi dan mempercepat "penggantian" perangkat keras yang jatuh dalam hitungan detik, secara otomatis meningkatkan mesin virtual di salah satu server langsung. Kata kunci - "mempercepat" dan "besi jatuh". Mesin virtual masih akan direstart. Toleransi Kesalahan VMware dan analog yang memungkinkan Anda untuk keluar dari reboot biasanya tidak digunakan dalam virtualisasi komersial karena konsumsi sumber daya dan penurunan kinerja mesin virtual yang dilindungi. Maka kesimpulannya: cloud komersial bukanlah obat mujarab untuk toleransi kesalahan, keuntungan utamanya adalah fleksibilitas dan skalabilitas.

Lihat dalam sejarah berapa banyak waktu henti yang harus Anda ganti atau perbaiki peralatan fisik. Setelah pindah ke cloud, jumlahnya akan berkurang, dan - ya, hidup akan menjadi sedikit lebih mudah bagi Anda. Anda tidak harus lari ke gudang atau menyimpan untuk server baru. Tapi sekarang lelucon virtualisasi akan ditambahkan ke crash besi.

Mungkin saja mesin sudah tidak tersedia, tetapi host fisik masih merespons. Cloud tidak akan melihat masalah ini. Atau justru sebaliknya: tuan rumah tidak merespons, tetapi semuanya baik-baik saja dengan mesin virtual. Dalam hal ini, virtualisasi akan mengangkatnya di tempat lain. Ini akan memakan waktu untuk memulai, dan lagi Anda akan menganggur tiba-tiba. Dan di bawah beban, itu bisa berakibat fatal. Karena itu, bahkan di cloud Anda perlu mengingat tentang redundansi. Omong-omong, memperingatkan penyedia virtualisasi tentang mesin mana yang saling mencadangkan adalah ide bagus. Kalau tidak, itu mungkin terjadi bahwa semua mobil Anda akan berakhir pada server fisik yang sama dan mati pada saat yang sama.

• Saat melakukan pengujian beban, masuk akal untuk merencanakan pengujian toleransi kesalahan di bawah beban.
  

Ini adalah saat, tepat selama tes beban, Anda menjatuhkan simpul di cluster dan melihat apa yang terjadi. Dengan cluster yang dikonfigurasi dengan benar dan sumber daya yang dialokasikan dengan benar, ini seharusnya tidak mempengaruhi hasil tes dan menyebabkan banyak kesalahan.

Tampaknya kami telah menyelesaikan semua "drum" yang khas. Sebelum membaca lebih lanjut, saya sarankan Anda menyegarkan detail teknis yang dijelaskan dalam artikel sebelumnya . Lagi pula, jika situs secara teknis tidak dapat menahan beban, kecepatan reaksi tidak akan menyelamatkan Anda.

Sekarang mari kita pikirkan tentang bagaimana mempersiapkan hal yang tidak biasa atau mendadak. Kita tidak dapat mencegah mereka dengan definisi, jadi tetap menyingsingkan lengan baju kita dan belajar bagaimana memperbaikinya secepat mungkin.

Langkah-langkah untuk menyelesaikan suatu insiden

Pertimbangkan apa yang merupakan waktu untuk menghilangkan kecelakaan:

1. Kecepatan deteksi kegagalan - penundaan pemantauan, menerima pesan dari pengguna, dll.
   
2. Waktu respons terhadap insiden yang terdeteksi - seseorang harus memperhatikan laporan dan menanganinya.
   
3. Saatnya untuk mengkonfirmasi kehadiran insiden - apakah ada anak laki-laki?
   
4. Saatnya menganalisis kejadian dan mencari solusi.
   
5. Saatnya menyelesaikan insiden dan masalah. Tidak selalu mungkin untuk memperbaiki semuanya saat pertama kali, dan tahap ini dapat memiliki beberapa iterasi.
   

Biasanya, layanan dukungan bertanggung jawab atas pemecahan masalah. Jika tim besar, masing-masing langkah ini dapat dilakukan oleh orang yang berbeda. Dan waktu, seperti yang Anda tahu, adalah uang. Dalam kasus kami, secara harfiah. Black Friday memiliki durasi yang tetap, dan pesaing waspada - pelanggan dapat menghabiskan segalanya dengan mereka. Oleh karena itu, sangat penting bahwa setiap karyawan mengetahui bidang tanggung jawab mereka dan bahwa insiden diselesaikan oleh konveyor.

Mari kita lihat setiap tahap secara terpisah, identifikasi poin masalah dan pertimbangkan cara untuk mengoptimalkannya dengan cepat.

Semua tip, petunjuk, dan rekomendasi di bawah ini bukanlah resep untuk "kehidupan yang indah", tetapi hal-hal spesifik yang dapat Anda terapkan dalam 3-4 bulan ke depan hingga Black Friday.

Deteksi kecelakaan

Dalam skenario yang paling tidak berhasil, klien memberi tahu Anda tentang masalahnya. Artinya, masalahnya sangat serius sehingga ia menghabiskan waktunya untuk melaporkan . Dalam hal ini, hanya klien yang sangat berdedikasi yang akan menulis atau menelepon, dan pengguna sederhana akan pergi dengan mengangkat bahu.

Selain itu, seringkali klien tidak memiliki akses langsung ke departemen TI. Karena itu, ia menulis ke beberapa info@business.ru, atau memanggil gadis-gadis dari pusat panggilan. Ketika informasi merayap ke TI, banyak waktu akan berlalu.

Misalkan kita memiliki banyak pelanggan setia, dan masing-masing menganggap itu tugasnya untuk menulis tentang masalah di TP. Sementara insiden diklasifikasikan sebagai masif, sementara eskalasi dan pengambilan keputusan, berjam-jam akan berlalu. Pada saat yang sama, panggilan individual dapat hilang, dan email info@business.ru terkadang tidak disapu selama berminggu-minggu.

Oleh karena itu, akan sangat berguna untuk memulai pemantauan independen terhadap parameter bisnis utama. Paling tidak - jumlah pengguna di situs, jumlah pembelian yang dilakukan dan rasio mereka. Data ini akan memungkinkan Anda untuk merespons dengan cepat jika terjadi kesalahan, dan secara signifikan mengurangi waktu untuk mengidentifikasi (dan menyelesaikan) masalah tertentu di situs.

Tidak ada pengguna? Kita perlu melihat ke mana mereka bisa pergi. Ada pengguna di situs, tetapi tidak ada penjualan? Ini adalah sinyal masalah, dan sangat terlambat. Pengujian skenario otomatis akan membantu Anda menemukan sesuatu terjadi di suatu tempat . Biasanya, tes otomatis berjalan pada build atau rilis, tetapi mereka baik-baik saja untuk pemantauan. Dengan bantuan mereka, Anda dapat melihat gangguan atau perlambatan beberapa proses bisnis penting melalui mata pengguna.

Tentu saja, jika Anda tidak memiliki pengujian skenario, selama beberapa bulan tersisa hingga Black Friday, Anda tidak akan mencakup semua tes produktif. Ya, dan mereka dapat memberikan beban yang serius. Tetapi dengan tes dari selusin proses dasar sangat mungkin untuk tepat waktu.

Ini juga sangat berguna untuk melacak waktu respons rata-rata server. Jika tumbuh, Anda dapat mengharapkan masalah penjualan. Data tersebut harus dipantau secara otomatis oleh sistem pemantauan.

Seperti yang Anda lihat, dengan pemantauan yang kompeten, Anda dapat mengurangi waktu yang diperlukan untuk mendeteksi masalah dari jam dan hari menjadi beberapa menit, dan kadang-kadang melihat masalah sebelum mencapai ketinggian penuh.

Waktu respons insiden

Kami melakukan pekerjaan dengan baik dan berkat pemantauan, kami langsung mendeteksi kegagalan. Sekarang Anda perlu memulai insiden, menetapkan prioritas, rute dan menugaskan orang yang bertanggung jawab untuk diproses lebih lanjut.

Dua hal penting di sini:

• Terima pemberitahuan masalah sesegera mungkin;
  
• Bersiaplah untuk segera memproses pemberitahuan.
  

Banyak spesialis TI tidak terbiasa dengan cepat menanggapi surat bahkan jika mereka memiliki klien di smartphone mereka. Jadi pemberitahuan penting tidak boleh dikirim melalui email.

Gunakan SMS untuk peringatan kecelakaan. Lebih baik lagi, terapkan bot dialer untuk kasus-kasus paling kritis. Saya pribadi belum melihat implementasi praktis dari bot seperti itu, tetapi jika sumber daya memungkinkan, mengapa tidak? Sebagai upaya terakhir, gunakan WhatsApp / Viber / Jabber. Sayangnya, Telegram di wilayah Federasi Rusia karena banyak alasan yang dapat dimengerti tidak dapat menjadi saluran yang dapat diandalkan untuk pemberitahuan darurat.

Mungkin juga bermanfaat untuk secara otomatis meningkatkan insiden jika tidak ada konfirmasi. Artinya, pemantauan akan memberi tahu baris berikutnya jika penerima utama notifikasi tidak merespons. Sistem ini akan memastikan Anda jika ada sesuatu (atau seseorang) yang salah.

Sekarang mari kita bicara tentang bagaimana memberikan respons cepat terhadap pesan kegagalan. Pertama, seseorang harus siap untuk bertanggung jawab menangani peringatan. Lansiran untuk seluruh tim bermanfaat, tetapi hanya untuk membuat orang selalu mendapatkan informasi terbaru.

Tanggung jawab kolektif adalah hal yang tidak dapat diandalkan ketika kecepatan diperlukan.

Jika Anda tidak menetapkan jam tangan pada jadwal yang jelas selama durasi tindakan, Anda mungkin menemukan bahwa selama force majeure seseorang akan tidur, dan seseorang tidak akan memiliki akses dari rumah. Seseorang akan berada di jalan. Dan faktanya, tidak ada seorang pun yang bisa mengatasi masalah itu dalam satu jam berikutnya. Tentu saja, Anda dapat menempatkan petugas tugas operasional sepanjang waktu, tetapi ada nuansa di sini. Anda tidak akan memaksa spesialis yang baik untuk terus bekerja dalam shift, yang berarti bahwa ketika Anda membutuhkannya, Anda masih harus mencari mereka dan membangunkannya. Dan mereka yang masih bekerja secara bergiliran, keluar dari konteks umum kehidupan tim. Ini memiliki efek paling fatal pada efektivitasnya untuk tugas yang direncanakan.

Apa yang akan menyelamatkan kita adalah bahwa dalam sebagian besar proyek kita perlu dengan cepat menanggapi pesan, memahami apa yang terjadi, dan sangat perlu diperbaiki sekitar 18 jam sehari. Biasanya, dari 6-8 pagi hingga 1-2 pagi hari berikutnya, hingga 90% lalu lintas dan penjualan.

Untuk menghindari overlay, cukup dengan menggeser jadwal kerja bagi mereka yang bertugas ke format seperti:

• 6: 00-15: 00 dan 17: 00-02: 00 - tugas "dari rumah";
  
• 15: 00-17: 00 - lindungi mereka yang ada di kantor;
  
• 02: 00-06: 00 - sedikit lalu lintas. Namun, tunjuk seseorang yang tidurnya tidak terlalu nyenyak.
  

Jangan lupa tentang akhir pekan. Masalah ini dapat diatasi dengan cara yang sama.

Jika aktivitas pengguna harian Anda didistribusikan secara berbeda, pilih jadwal yang serupa di mana situs prime time tidak akan pergi tanpa pengawasan.

Menjadi bertugas berarti bertanggung jawab untuk memproses acara pemantauan, panggilan dari saluran sebelumnya (dukungan pelanggan) dan memantau sistem secara keseluruhan. Tapi sementara semuanya tenang, petugas jaga terlibat dalam pekerjaan utamanya.

Pastikan untuk mulai bertugas beberapa hari sebelum dimulainya beban. Pertama, ini akan memastikan sekali lagi bahwa setiap orang memiliki semua akses. Kedua, perubahan dalam mode operasi adalah stres, banyak yang perlu "tenang." Dan akan lebih baik jika periode kecanduan tidak bersamaan dengan panas utama.

Hebat, peringatan datang, dan orang-orang itulah yang harus meresponsnya. Tetapi waktu respons orang yang bertugas sangat dipengaruhi oleh adanya peringatan yang tidak perlu dan tidak diproses, serta pemberitahuan, yang pada prinsipnya tidak melibatkan tindakan apa pun. Sangat penting untuk tidak meninggalkan lansiran yang tidak diproses. Jika banyak kejadian serupa terjadi secara teratur, selidiki penyebabnya dan perbaiki. Seharusnya tidak ada alarm aktif di sistem pemantauan sama sekali .

Dari pengalaman, jika sesuatu tidak dapat diperbaiki dengan cepat atau jika tidak membutuhkan perbaikan, tetapi masih "berkedip", lebih baik untuk menekan notifikasi dan membuat tugas untuk pengembangan. Alarm yang terus berkedip cepat atau lambat menjadi akrab dan tidak lagi menarik perhatian. Masalahnya adalah bahwa ketika masalah nyata muncul, orang dapat membingungkan bola lampu dan mengabaikan peristiwa yang sangat penting.

Konfigurasi dan prioritas kejadian yang tepat dalam sistem pemantauan masih sangat penting. Sistem harus memberi tahu Anda apa yang perlu diperbaiki. Tentang kegagalan spesifik atau risiko terjadinya mereka. Anda tidak akan memperbaiki Penggunaan CPU 100%? Anda akan menghilangkan latensi tinggi pada server WEB, karena Penggunaan CPU adalah informasi untuk debugging, bukan masalah. Jika pada Black Friday prosesor dimuat pada 100% pada target load, kecepatan respons dan memperhitungkan stok akun - ini berarti Anda telah menghitung semuanya dengan benar.

Pemanfaatan sumber daya sistem harus dikontrol, tetapi ini adalah tugas yang sedikit berbeda, yang penting untuk perencanaan sumber daya dan mengidentifikasi bidang-bidang dampak kecelakaan.

Kami menyiapkan acara, sekarang penting untuk memprioritaskan dengan benar apa yang akan kami perbaiki. Untuk melakukan ini, kita akan mencari tahu apa perbedaan antara tingkat peringatan Kritis dan Peringatan. Biarkan saya memberi Anda beberapa contoh yang berlebihan, tetapi dapat dimengerti.

Penting - ini adalah ketika Anda pergi ke nenek di kereta bawah tanah, dapatkan peringatan dan pergi ke stasiun terdekat. Anda mengambil laptop, duduk di bangku kecil dan mulai bekerja - ada penghentian penjualan atau kerugian besar muncul. Artinya, Kritis adalah sesuatu yang memiliki dampak langsung, meskipun signifikan terhadap pengguna.

Peringatan - ini adalah saat Anda tidak meninggalkan pekerjaan sampai Anda memperbaikinya. Melempar segalanya dan berlari untuk membantu demi peringatan tidak perlu. Anda dapat menyelesaikan / menyelesaikan dan membuat keputusan. Misalnya, ada risiko jelas masalah kritis seperti server yang dijatuhkan dari pasangan HA, kesalahan jatuh di log dan sejenisnya. Jika Anda tidak memalu dan dengan hati-hati memperbaiki kejadian seperti itu (dan juga menggali penyebabnya dan melakukan pekerjaan untuk mencegahnya), akan ada sangat sedikit dari mereka.

Hal lain yang sering dilupakan. Jangan membuang admin hanya bertugas. Pastikan untuk menarik pengembang dengan membentuk pasangan kerja untuk setiap shift. Ini akan berguna bagi kita di langkah selanjutnya.

Jika proyek ini kompleks secara fungsional, masuk akal untuk mengirim konsultan, analis, penguji, dan semua orang lain yang mungkin berguna saat bertugas. Pastikan ketersediaannya setidaknya melalui panggilan. Spesialis harus mengkonfirmasi masalah (atau sebaliknya) dan membantu dengan pelokalan fungsional - ketika Anda harus membesarkan seseorang untuk diperbaiki, ini akan menghemat waktu Anda. Saya akan membahas masalah ini secara lebih rinci di bagian selanjutnya.

Dan poin penting terakhir. Setiap petugas jaga harus benar-benar mengetahui kontak dan bidang tanggung jawab semua rekannya dalam situasi darurat. Jika dia tidak bisa menyelesaikan masalah sendiri dan dalam panik mulai mencari penyelamat yang tersedia, kekacauan akan datang, karena itu Anda akan kehilangan banyak waktu.

Kepatuhan terhadap aturan sederhana ini akan membantu menghindari masalah karena pemberitahuan yang terlewat dan memastikan bahwa ketika keadaan darurat datang (baca “Black Friday” dan “emergency”), orang akan dapat menyelesaikan masalah dengan segera.

Konfirmasikan Insiden

Langkah selanjutnya setelah menerima pemberitahuan adalah untuk memahami apa yang sebenarnya salah dan apakah ada masalah pada prinsipnya: segera menentukan siapa yang benar, pengguna atau sistem, tidak selalu mudah. Faktanya adalah bahwa peringatan yang sama dapat ditafsirkan secara berbeda tergantung pada sudut pandang.

, , ( ), . , . , . , , «» , .

, . , ! - , «».

- . «» . , , .

— , , . , . , , . — - « », « » « , ».

, , , , «». , , . — , , , . : , , .

, . , . . , , . — , : .

. -, , , – , , , , ( , ) .



. .

. , .

, . , , :

• ;
  
• ;
  
• ;
  
• ;
  
• (, ..).
  

, , , . -. , ELK .

, , .

- , , , .

, — . , , . , . , .

- , . , , , — .

: , , , . , 3 :

1. ;
   
2. ;
   
3. .
   

. ( ). , , -, , - .

. . , , , . , , — .

. , - - , , , - . . . , , , .

, , . , . , , « » .

– SLA. SLA – , , . SLA , . , - . , .

— , . , , . .

Sejauh ini, hanya itu yang ingin saya sampaikan tentang topik ini. Saya akan senang jika saran saya, ditransfer ke realitas bisnis Anda, memungkinkan saya untuk bertahan dengan beban tinggi dengan tenang dan nyaman.

Jika Anda ingin nasihat tentang bagaimana bertindak dalam situasi Anda, saya mengundang Anda ke seminar saya Black Friday. Rahasia Kelangsungan Hidup. " Dalam format tanya jawab, kita akan berbicara tentang mempersiapkan situs untuk pertumbuhan lalu lintas dan mendiskusikan rincian teknis dan organisasi dari proses ini.

Seminar akan diadakan pada 16 Agustus di Moskow. Karena acara ini akan menjadi ruang yang cukup (maksimum 25 orang), janji diperlukan. Dan saya menunggu sisanya untuk diskusi di komentar. :)