Mari kita tinjau secara singkat beberapa operasi AWS sebagai AIGC Startup SRE, semoga dapat membantu semua orang Sejak awal orientasi untuk menemukan bahwa klaster utama kami adalah USE1, saya mulai melakukan beberapa persiapan. Ini adalah hal utama yang saya lakukan 1. Beberapa database inti kami telah dicadangkan di beberapa tempat, membentuk cadangan USE1, Tokyo, dan SG. Dengan cara ini, dalam kasus ekstrim, kami kehilangan sebagian data, tetapi kami juga dapat memastikan kelanjutan layanan 2. Rekonstruksi klaster pengujian SG kami dari EC2 asli itu sendiri K3S ke klaster AWS EKS standar. Hal ini memungkinkan Anda untuk dengan cepat menghangatkan klaster jika terjadi bencana dan menggunakan kembali komponen AWS yang ada. Meminimalkan biaya perubahan manifes 3. Sortir SOP secara singkat, termasuk pengumuman pengguna, peralihan DNS, pemblokiran versi, dll Kembali hari ini, sekitar 10 menit setelah insiden AWS, saya menemukan bahwa ada pod baru di kontainer kami yang tidak dapat diatur. Setelah mengonfirmasi dengan AWS Support bahwa itu adalah masalah USE1, saya menyadari bahwa peristiwa ECR harus terkait dengan peristiwa lainnya, jadi saya memutuskan untuk mulai menangani peristiwa tingkat Tier1 sesuai dengan rencana saya sendiri (untuk SRE, hal semacam ini lebih baik salah daripada terlewatkan) T+0 menit, saya mengeluarkan pengumuman semua staf dan mulai masuk ke mode darurat. Saya mengatur pertemuan publik semua tangan. Semua orang dapat bergabung kapan saja T+2 menit, saya mengkonfirmasi bahwa acara tersebut secara bertahap berkembang seperti yang saya harapkan, dan saya mengeluarkan dua instruksi, 1. Melarang penggabungan/penerapan kode apa pun secara menyeluruh (terutama untuk mencegah sumber daya yang baru dibuat menyebabkan rotasi pod memengaruhi lalu lintas), 2. Silakan siapkan pengumuman untuk siswa operasi T+3 menit, saya mulai mengikuti SOP, memulai pemulihan database di wilayah SG, dan berjencad untuk membuat dependensi seperti OpenSearch/Redis, dll T+5 menit, kami mulai secara resmi mengonfirmasi masalah spesifik dependensi hulu dan hilir, dan mengonfirmasi bahwa layanan inti yang baru diluncurkan terpengaruh T+10 menit, pengumuman penangguhan layanan kami dan pengumuman yang terpengaruh untuk layanan lainnya akan dikeluarkan T+10 menit, saya meminta dua orang lain untuk membantu menyiapkan ECR baru dan membersihkan sumber daya yang ada di lingkungan pengujian pada saat yang sama, dan menyinkronkan CTO, dalam kasus ekstrim, kami mungkin memiliki keputusan untuk mempertahankan pengalaman dan kehilangan data. T+15 menit, kami akhirnya mengkonfirmasi bahwa sumber daya yang dibuat sejauh ini dan arah lalu lintas masuk tidak akan terlalu terpengaruh. Peralihan tertunda, tetapi kami terus menyiapkan sumber daya yang relevan T+30 menit, database pertama kami dipulihkan T+40 menit, database kedua kami dipulihkan T+1h, semua infra inti terkait kami, RDS/ES/Redis siaga, dan opsi pengoptimalan seperti master-slave diatur sesuai dengan arsitektur produksi. Pada saat yang sama, kami juga mulai meluncurkan layanan baru di klaster baru Untungnya, pada akhirnya, kerusakan AWS tidak memengaruhi semua layanan kami. Kita tidak perlu berurusan dengan pekerjaan perbaikan data yang rumit setelah beralih lalu lintas Setelah sekitar T+2h hingga T+3h, saya secara resmi memberi tahu semua staf dan keadaan darurat dicabut. Untuk amannya, kami masih akan tutup untuk tampil malam ini. Melihat kembali seluruh insiden itu, saya bisa berbuat lebih banyak 1. Mengungkapkan SOP kasus ekstrim yang saya siapkan sendiri kepada seluruh karyawan. Ini memastikan bahwa meskipun saya tidak online, seseorang dapat menggantikan saya 2. Kita dapat melakukan beberapa latihan lanjutan 3. Pesanan bisa lebih menentukan Sudah cukup, sedikit berbagi, semoga bisa membantu semua orang