View a markdown version of this page

Tahap 4: Beroperasi - AWS Panduan Preskriptif

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Tahap 4: Beroperasi

Anda telah membangun aplikasi yang tangguh dan mengujinya. Sekarang realitas sehari-hari menjaganya tetap berjalan. Tetapi dalam startup, Anda tidak dapat menonton semua operasi, dan Anda tidak boleh mencobanya. Kuncinya adalah tetap waspada terhadap apa yang penting tanpa memberikan terlalu banyak metrik atau membebani tim Anda.

Mulailah dengan perspektif pelanggan. Burung kenari Amazon CloudWatch Synthetics bertindak sebagai pelanggan otomatis. Mereka terus menguji perjalanan pengguna yang kritis. Mintalah mereka masuk, simulasikan pembelian menggunakan akun uji, atau akses fitur-fitur utama, terutama selama jam-jam tersibuk Anda. Ini membantu Anda memahami pengalaman pelanggan dan membantu Anda menangkap masalah sebelum pengguna nyata melakukannya. Ketika kenari gagal, Anda langsung tahu bahwa ada sesuatu yang salah dari sudut pandang pelanggan.

Bangun di atas fondasi ini dengan pemantauan terfokus pada infrastruktur pendukung. Sinyal apa yang memberi tahu Anda bahwa ada masalah? Amazon CloudWatch membantu Anda membangun dasbor yang melacak tanda-tanda ini. Jangan hanya memantau metrik teknis; ikat mereka dengan dampak bisnis. Misalnya, penggunaan CPU yang tinggi penting, tetapi itu karena itu mungkin menurunkan pengalaman pelanggan yang Anda lacak dengan kenari.

Sebagai pendekatan praktis, petakan pemantauan Anda ke perjalanan pelanggan Anda. Jika Anda menjalankan platform perangkat lunak sebagai layanan (SaaS), Anda mungkin peduli dengan waktu respons API, tingkat keberhasilan otentikasi, dan ketersediaan fitur inti. Siapkan peringatan yang memberi tahu Anda saat metrik ini melayang. Namun, bersikaplah selektif. Setiap peringatan harus menuntut tindakan. Jika tim Anda mulai mengabaikan peringatan karena “mungkin bukan apa-apa,” Anda telah menyetel terlalu banyak atau melacak metrik yang salah.

Rutekan peringatan ini melalui alat yang sudah digunakan tim Anda. Jika teknisi Anda tinggal di aplikasi perpesanan tertentu, kirim peringatan di sana. Tujuannya adalah kesadaran cepat tanpa menciptakan proses baru. Ketika peringatan menyala, tim Anda harus tahu persis apa artinya dan apa yang harus dilakukan.

Jaga agar dokumentasi operasional Anda ramping dan praktis. Simpan runbook dengan kode Anda di kontrol versi, tetapi ingat bahwa itu bukan novel. Ketika sesuatu rusak, tim Anda membutuhkan langkah yang jelas dan dapat ditindaklanjuti. Setiap peringatan harus ditautkan ke runbook yang sesuai, dan setiap runbook harus menjawab tiga pertanyaan:

  • Apa yang pecah?

  • Mengapa ini penting?

  • Bagaimana cara memperbaikinya?

Menerapkan proses manajemen insiden sederhana. Anda tidak memerlukan kerangka kerja yang rumit, cukup definisi yang jelas tentang apa yang merupakan insiden dan siapa yang harus dihubungi ketika segala sesuatunya meningkat. Simpan log insiden karena membantu Anda meningkatkan ketahanan aplikasi Anda.

Kuncinya adalah menemukan sweet spot antara kewaspadaan dan overhead. Gunakan AWS alat untuk mengotomatiskan apa yang Anda bisa, fokus pada metrik pemantauan yang memengaruhi pelanggan, dan menjaga proses Anda cukup ringan untuk berkembang seiring pertumbuhan Anda.

Bab berikutnya mengeksplorasi bagaimana menumbuhkan pola pikir ketahanan tanpa mengorbankan kecepatan dan inovasi yang membuat startup istimewa. Pada akhirnya, ketahanan adalah tentang orang-orang seperti halnya tentang teknologi.