Cum să construiți o pagină de stare în care clienții să aibă cu adevărat încredere

Majoritatea paginilor de stare există. Puține sunt de încredere. O pagină care este mereu verde în timpul întreruperilor este mai rea decât absența unei pagini, deoarece îi învață pe clienți să nu mai caute. O pagină de stare de încredere are patru proprietăți: este onestă cu privire la ceea ce este defect, este rapidă în a recunoaște incidentele, încadrează cu atenție impactul și răspunde la întrebarea «mă afectează asta?» fără ca cititorul să fie nevoit să caute. Acest ghid acoperă cum să proiectați una.

Ce își doresc cu adevărat clienții de la o pagină de stare

Două întrebări determină fiecare vizită la o pagină de stare. Clienții vor să știe dacă lucrul de care le pasă este defect și dacă cineva a observat. Restul este decor.

Dacă pagina răspunde la ambele întrebări la prima vedere, clienții au încredere în ea și încetează să mai apeleze la asistență. Dacă nu răspunde la niciuna, fiecare incident produce cinci tichete de asistență suplimentare și o pierdere lentă de credibilitate. Designul vizual contează mai puțin decât structura a ceea ce este afișat deasupra liniei de pliere.

Cele patru proprietăți ale unei pagini de încredere

Patru proprietăți separă o pagină de stare utilă de una de vanitate. Faceți corect toate cele patru și clienții vor avea încredere în pagină în timpul unui incident real.

• Onestitate. Dacă ceva este defect, apare ca defect. Dacă nu știți încă, pagina spune că se investighează. Verde în timpul unui incident real distruge încrederea pentru totdeauna.
• Viteză. Incidentele sunt postate în câteva minute de la detectare. O actualizare de stare care rămâne în urma întreruperilor reale cu o oră este tratată ca text de marketing.
• Claritatea domeniului de aplicare. Clientul poate spune, în câteva secunde, dacă incidentul afectează ceea ce folosește. Regiunea, zona produsului și severitatea sunt cele trei dimensiuni de etichetat.
• Limbaj simplu. Actualizările sunt scrise cu aceeași voce pe care ați folosi-o pentru a explica incidentul unui prieten, nu în proză corporativă la diateza pasivă.

Actualizări de incidente care funcționează

Majoritatea șabloanelor de pagini de stare adoptă implicit un ton pasiv, evaziv. «Investigăm rapoarte despre latență crescută.» Acest lucru se citește ca o deviere. Modelul care construiește încrederea este inversul: numiți ce este defect, numiți impactul asupra utilizatorului, numiți ce faceți în privința asta.

O primă actualizare bună sună așa: «Autentificările eșuează pentru aproximativ 30% dintre clienții din regiunile UE. Trecerea pe baza de date de rezervă este în curs, timpul estimat 10 minute.» O rezoluție bună sună așa: «Autentificările sunt restabilite. Cauza principală a fost un script de failover blocat. Am adăugat un watchdog astfel încât acesta să nu se mai poată bloca silențios.» Ambele sunt scurte. Ambele numesc impactul, acțiunea și urmărirea.

Încadrarea corectă a impactului

O singură pagină de stare globală este abstractizarea greșită odată ce aveți mai mult de o linie de produse sau o regiune. Clientul cu o implementare exclusiv în SUA nu este interesat că regiunea dumneavoastră UE are latență crescută.

• Împărțiți pagina pe componente: API-ul, panoul de control, ingestia, facturarea etc. Afișați starea per componentă, nu un singur indicator global.
• Adăugați o dimensiune regiune sau mediu acolo unde se aplică. Marcați explicit regiunea afectată în timpul incidentelor.
• Afișați ultimele 90 de zile de incidente sub starea live. Vizualizarea istorică este ceea ce verifică vizitatorii pentru a decide dacă sunteți suficient de fiabili pentru a paria pe voi.
• Dacă oferiți, expuneți un flux RSS sau JSON astfel încât clienții cărora le pasă să se poată abona în propriile instrumente.

Mentenanță programată fără tăcere

Mentenanța programată este partea cea mai ușoară a paginii de stare de făcut corect și una dintre cele mai omise. Postați fereastra cu 48 de ore în avans, rezumați ce va fi afectat și ce nu și postați o continuare care confirmă finalizarea.

Tratați mentenanța programată cu același ton ca actualizările de incidente. Numiți fereastra. Numiți serviciile afectate. Numiți impactul. O postare curată de mentenanță previne un tichet de asistență. Una vagă creează o duzină.

Fiabilitatea paginii de stare în sine

Găzduiește pagina de stare într-un loc independent de infrastructura ta principală. Dacă pagina de stare returnează aceeași eroare de bază de date ca dashboardul tău în timpul unei căderi a bazei de date, pagina în sine devine parte din incident. O pagină de stare care se încarcă de la un furnizor separat, dintr-o regiune separată sau dintr-un CDN static este acel mic detaliu de disciplină arhitecturală care se dovedește valoros prima dată când ai o cădere reală. Majoritatea echipelor descoperă acest lucru pe calea grea.