Panduan

Cara Bina Halaman Status: Komponen, Insiden dan Semakan Uptime

Halaman status memberitahu pengguna anda, di satu tempat, sama ada perkhidmatan anda berfungsi. Untuk membinanya, anda perlukan senarai komponen (laman web, API, pembayaran, penghantaran e-mel), status semasa bagi setiap satu, insiden dengan kemas kini beserta cap masa, sejarah insiden lalu, dan langganan secara pilihan supaya orang mendapat tahu tentang masalah tanpa perlu menyemak. Halaman itu sendiri mudah. Keputusan penting ialah di mana ia dijalankan: halaman status mesti kekal aktif apabila apl anda tidak berfungsi, jadi ia tidak patut berkongsi hosting, pangkalan data atau saluran deploy dengan perkara yang dilaporkannya.

Untuk apa halaman status

Apabila sesuatu rosak, pengguna mahu tahu tiga perkara: adakah ini hanya saya, adakah anda sedar, dan bila ia akan dibaiki. Halaman status menjawab ketiga-tiganya tanpa banjir tiket sokongan. Ia juga membina kepercayaan dari masa ke masa, kerana sejarah insiden yang jelas dengan penerangan yang jujur menunjukkan cara anda mengendalikan masalah.

Ia bukan changelog. Ciri baharu pergi ke halaman changelog; gangguan dan penyelenggaraan pergi ke sini.

Apa yang diperlukan halaman itu

Data

JadualMedan utama
KomponenNama (Aplikasi web, API, Pembayaran, Penghantaran e-mel), penerangan, status semasa, susunan paparan, kumpulan
InsidenTajuk, impak (kecil, major, kritikal), status (Menyiasat, Dikenal pasti, Memantau, Diselesaikan), komponen terjejas, masa mula, masa diselesaikan
Kemas kini insidenInsiden, mesej, status pada masa itu, masa disiarkan, disiarkan oleh
Tetingkap penyelenggaraanTajuk, komponen terjejas, masa mula dan tamat yang dijadualkan, mesej
PelangganE-mel, sah atau belum, komponen yang mereka ambil berat, token nyahlanggan

Status komponen biasanya senarai tetap yang pendek: Beroperasi, Prestasi merosot, Gangguan separa, Gangguan major, Dalam penyelenggaraan.

Halaman

  • Halaman status awam: sepanduk keseluruhan ("Semua sistem beroperasi" atau status paling teruk semasa), setiap komponen dengan statusnya, mana-mana insiden aktif dengan kemas kininya, penyelenggaraan akan datang, dan jalur sejarah 90 hari jika anda ada data semakan.
  • Halaman insiden: garis masa penuh kemas kini bagi satu insiden, dengan URL sendiri supaya sokongan boleh memautkannya.
  • Sejarah: insiden lalu mengikut bulan.
  • Langgan: pendaftaran e-mel dengan pengesahan dan keutamaan mengikut komponen.
  • Pentadbir: cipta insiden, siarkan kemas kini, tukar status komponen, jadualkan penyelenggaraan.

Kebenaran

Orang awam melihat semua yang diterbitkan. Hanya pasukan anda boleh menyiarkan. Asingkan log masuk pentadbir daripada sistem log masuk apl utama anda jika boleh, supaya gangguan pada penyedia auth anda tidak mengunci anda daripada halaman status anda sendiri.

Keputusan utama: kekalkan kebebasannya

Di sinilah kebanyakan halaman status buatan sendiri gagal. Jika halaman status anda:

  • berjalan pada pelayan atau akaun hosting yang sama dengan apl anda,
  • membaca daripada pangkalan data yang sama,
  • berada di sebalik tetapan domain atau konfigurasi CDN yang sama,
  • atau dideploy oleh saluran yang sama,

maka banyak gangguan akan menumbangkannya juga, tepat ketika orang memerlukannya. Langkah praktikal:

  • Hosting berasingan. Projek atau pembekal yang berbeza daripada apl utama.
  • Subdomain sendiri, seperti status.contoh.com, ditunjuk secara berasingan dalam DNS. Lihat cara domain dan DNS berfungsi.
  • Data sendiri. Insiden disimpan dalam storan halaman status itu, bukan pangkalan data apl anda.
  • Sandaran statik. Sesetengah pasukan menjadikan halaman awam statik dan membinanya semula setiap kali ada kemas kini, supaya hampir tiada yang boleh rosak.

Kemas kini manual atau semakan automatik

Manual (mulakan di sini)

Pasukan anda menyiarkan insiden dan menukar status komponen secara manual dari halaman pentadbir. Inilah cara kebanyakan halaman status berfungsi dalam amalan, kerana pertimbangan manusia ("pembayaran perlahan untuk sesetengah jenis kad") lebih berguna daripada titik merah automatik.

Untuk tahu tentang masalah dengan cepat, gunakan pemantau uptime luaran yang menyemak apl anda setiap minit atau lebih dan memberi amaran melalui e-mel, SMS atau sembang. Banyak perkhidmatan pemantauan menawarkan tier percuma.

Automatik

Automasi bermakna sesuatu memeriksa setiap komponen secara berkala dan mengemas kini statusnya. Ia memerlukan kod yang berjalan mengikut jadual, dari luar infrastruktur apl utama anda. Dua corak lazim:

  • Sebuah pemantau luaran memanggil halaman status anda melalui webhook apabila semakan gagal atau pulih, dan halaman status mengemas kini komponen itu.
  • Satu kerja berjadual dalam hosting halaman status itu sendiri memeriksa setiap komponen dan merekod hasilnya. Semak cara hosting anda mengendalikan tugas berjadual sebelum bergantung padanya; panduan kami tentang menjalankan kerja latar belakang menerangkan pilihannya.

Perubahan automatik boleh berkelip (naik, turun, naik) pada rangkaian yang perlahan. Minta dua atau tiga kegagalan berturut-turut sebelum menukar status, dan biarkan manusia mengesahkan sebelum gangguan major diumumkan.

Menulis kemas kini insiden

  • Siarkan awal. "Kami sedang menyiasat laporan kegagalan log masuk" dalam beberapa minit lebih baik daripada mesej yang sempurna satu jam kemudian.
  • Nyatakan apa yang pengguna perasan, bukan apa yang rosak secara dalaman.
  • Janjikan masa kemas kini seterusnya, dan tepatinya.
  • Tutup dengan ringkasan pendek apabila selesai: apa yang berlaku, berapa lama, dan apa yang anda akan ubah.

Arahan pertama yang berfungsi

Bina halaman status berdiri sendiri untuk apl kami Parcelio, dihoskan berasingan di status.parcelio.com. Komponen: Laman web, API Penjejakan, Pemberitahuan, Pembayaran, setiap satu dengan status Beroperasi, Prestasi merosot, Gangguan separa, Gangguan major atau Dalam penyelenggaraan. Halaman awam menunjukkan sepanduk keseluruhan menggunakan status paling teruk semasa, setiap komponen dengan statusnya, insiden aktif dengan kemas kini beserta cap masa (yang terbaharu dahulu), penyelenggaraan akan datang, dan senarai insiden lalu mengikut bulan. Setiap insiden mempunyai halamannya sendiri. Tambah halaman pentadbir yang dilindungi kata laluan untuk mencipta insiden (tajuk, impak, komponen terjejas), menyiarkan kemas kini (mesej dan status: Menyiasat, Dikenal pasti, Memantau, Diselesaikan), menukar status komponen dan menjadualkan penyelenggaraan. Tambah endpoint POST /api/check-result yang menerima nama komponen dan naik/turun daripada pemantau luaran, dilindungi token rahsia, dan hanya menandakan komponen sebagai Prestasi merosot selepas tiga kegagalan berturut-turut. Simpan semuanya dalam pangkalan data apl ini sendiri. Reka bentuk yang ringkas dan tenang, dimuatkan dengan pantas pada telefon.

Langkah membina

  1. Halaman awam dan pentadbir dengan insiden manual. Ini sahaja sudah menjadi halaman status yang berfungsi.
  2. Hoskan secara berasingan dan tunjukkan subdomain ke sana.
  3. Halaman insiden dan sejarah.
  4. Tetingkap penyelenggaraan.
  5. Langganan. Pendaftaran e-mel dengan pengesahan dua langkah dan pemberitahuan tentang insiden baharu serta kemas kini. E-mel memerlukan pembekal; lihat cara menghantar e-mel dari apl anda.
  6. Webhook pemantau jika anda mahukan perubahan status automatik.
  7. Jalankan latihan. Cipta insiden olok-olok, siarkan kemas kini, selesaikannya, semak e-mel, kemudian padamkannya.

Kesilapan lazim

  • Menghoskannya bersama apl. Kesilapan paling kerap dan paling serius.
  • Halaman yang sentiasa berkata "Semua sistem beroperasi". Jika ia tidak pernah menunjukkan masalah, pengguna berhenti mempercayainya.
  • Tiada cap masa atau zon waktu. Sentiasa tunjukkan masa bersama zonnya.
  • Bergantung pada log masuk apl utama untuk halaman pentadbir.
  • Senyap antara kemas kini. "Tiada perubahan, masih berusaha" ialah kemas kini yang sah.
  • Status automatik yang berkelip. Perlukan kegagalan berulang sebelum sebarang perubahan.

Bila perkhidmatan halaman status sedia ada lebih baik

Perkhidmatan halaman status yang dihoskan dibina untuk masalah kebebasan itu: ia berjalan pada infrastruktur berasingan, mengendalikan pemberitahuan pelanggan melalui e-mel dan SMS, dan selalunya termasuk pemantauan serta integrasi dengan alat insiden. Jika uptime sebahagian daripada apa yang pelanggan bayar, atau anda mempunyai kewajipan kontrak untuk melaporkan insiden, perkhidmatan khusus biasanya berbaloi. Ramai menawarkan tier percuma atau murah untuk pasukan kecil, jadi semak dahulu sebelum membina.

Bina sendiri apabila anda mahu kawalan penuh ke atas reka bentuk dan ayat, apabila keperluan anda mudah (beberapa komponen, kemas kini manual), atau apabila halaman status adalah sebahagian daripada produk yang anda bina untuk orang lain.

Membinanya dengan Mythex

Di Mythex anda boleh membina halaman status sebagai projek sendiri, berasingan daripada apl utama, yang memberikan hosting berasingan dan pangkalan data sendiri. Terangkannya dalam sembang, semak dalam pratonton langsung, kemudian terbitkan dan sambungkan subdomain seperti status.domainanda.com (domain tersuai tersedia pada Pro). Ingat bahawa apl Mythex yang diterbitkan dan pangkalan datanya tidur apabila tidak digunakan dan bangun pada lawatan seterusnya, jadi muatan pertama selepas tempoh senyap mungkin lebih perlahan; halaman yang ringkas dan ringan membantu.

Mythex belum mendokumentasikan tugas berjadual, jadi untuk semakan automatik gunakan pemantau uptime luaran yang memanggil endpoint webhook dalam halaman status anda (lihat resipi webhook). Pemberitahuan e-mel kepada pelanggan melalui pembekal anda sendiri, dengan kunci disimpan sebagai rahsia projek (resipi hantar e-mel).

Soalan lazim

Apakah itu halaman status?

Halaman awam yang menunjukkan sama ada setiap bahagian perkhidmatan anda berfungsi, menyenaraikan insiden semasa dan lalu dengan kemas kini beserta cap masa, dan selalunya membolehkan orang melanggan notis. Ia mengurangkan beban sokongan semasa gangguan.

Patutkah halaman status saya dihoskan bersama apl saya?

Tidak. Jika ia berkongsi hosting, tetapan domain atau pangkalan data dengan apl anda, ia boleh terhenti dalam gangguan yang sama yang sepatutnya dilaporkannya. Hoskan secara berasingan, pada subdomain seperti status.domainanda.com.

Adakah saya perlukan pemantauan automatik?

Ia membantu, tetapi tidak wajib untuk bermula. Ramai pasukan kecil menyiarkan insiden secara manual dan menggunakan pemantau uptime luaran untuk memberi amaran kepada mereka. Perubahan status automatik boleh datang kemudian.

Apa yang perlu dinyatakan dalam kemas kini insiden?

Perkara yang terjejas, apa yang akan dilihat pengguna, apa yang sedang anda lakukan, dan bila kemas kini seterusnya akan tiba. Ringkas, jelas dan dengan cap masa, walaupun kemas kini itu hanya 'masih menyiasat'.

Mythex · Pricing · Bina apa sahaja dengan AI · Templat laman web dan aplikasi · Mythex dibandingkan · Glosari pembinaan aplikasi AI · Alat percuma untuk membina aplikasi dengan AI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)