Како да откриете дека производот ви е расипан пред тоа да го сторат клиентите

Постои еден вид е-порака што ниту еден основач не сака да ја прочита: „Здраво, дали работи формуларот за регистрација? Пробав трипати.“ Додека таа порака ќе пристигне, формуларот обично е расипан со часови. Сите што налетале на него пред тој клиент едноставно заминале.

Повеќето мали тимови немаат следење освен проверки за достапност и надеж дека некој ќе забележи. Тоа не е немар — тоа е разумен одговор на индустрија што ја продава набљудливоста како корпоративна дисциплина што бара табли, дежурства и платформски тим. Не е така. Мал тим може да ја добие најголемата вредност од поставеност што бара едно попладне и еден час месечно за одржување.

Проверките за достапност се подот, а не таванот

Монитор за достапност што ја проверува вашата почетна страница на секои пет минути ви кажува едно: дали серверот одговара. Тоа е најнеинтересниот начин на кој нештата паѓаат. Во пракса, вашата почетна страница останува достапна додека:

• Контакт-формуларот тивко паѓа зашто истекол пристапен податок за SMTP
• Наплатата фрла грешка 500 кај еден начин на плаќање
• Скрипта од трета страна го блокира прикажувањето во Safari
• Пребарувањето враќа празни резултати зашто задача за индексирање пропаднала
• Најавата работи, но колачињата за сесија не се поставуваат на мобилен

Секое од овие е невидливо за проверка на почетната страница и директно чини приход. Следењето на достапноста вреди да го имате, но третирајте го како детектор за чад, а не како дијагноза.

Надградбата е синтетичка проверка на вашиот критичен пат. Изберете еден-два тека што ви носат пари — регистрација, наплата, испраќање контакт-формулар, што и да е — и пуштајте скриптиран прелистувач низ нив на секои петнаесет минути. Повеќето услуги за следење го поддржуваат ова. Ако вашата не го поддржува, Playwright скрипта на закажана задача во вашиот процес прави исто, бесплатно. Правилото: следете ја трансакцијата, а не страницата.

Следењето грешки е работата со најголем ефект што сѐ уште не ја правите

Ако инсталирате точно една алатка, инсталирајте следење грешки (Sentry, Rollbar, Bugsnag — конкретниот добавувач е далеку помалку важен од тоа да имате еден). Поврзете го и со серверот и со фронтендот. Трае дваесет минути.

Што добивате: секој исклучок на кој наидуваат вашите корисници, групиран по основна причина, со траг на повици, прелистувач и дејствата што довеле до него. Престанувате да погодувате што значи „не проработи“. Две работи го прават ова корисно наместо шум:

Поставете верзија на изданието при секое поставување. Без неа не можете да утврдите дали грешката е нова или стара. Со неа, скокот по поставување е веднаш припишлив и можете да се вратите назад врз основа на доказ, а не на инстинкт.

Тријажирајте агресивно првата недела. Нова инсталација ќе покаже стотици грешки, повеќето од нив шум од проширувања во прелистувачот и сообраќај од ботови. Решавајте ги или игнорирајте ги безмилосно додека сандачето не се приближи до нула. Следачот на грешки помага само ако новиот проблем е видливо нов. Ако вашата табла постојано покажува 400 нерешени проблеми, таа е декорација.

Предупредувајте за симптоми, а не за причини

Инстинктот е да се предупредува за инфраструктурата: процесор, меморија, диск. За мал производ на управуван хостинг, тоа е претежно потрошено внимание. Високо оптоварување на процесорот што никој не го забележува не е инцидент. Стапка на успешна наплата што паднала за 40% — е, дури и ако секој серверски показател изгледа добро.

Предупредувајте за работи што клиентот би ги почувствувал:

• Стапка на грешки над вашата нормална основна линија
• Синтетичка проверка на критичниот пат што паѓа двапати по ред
• Обем на конверзии или регистрации што паѓа значително под истиот час минатата недела
• Редица позадински задачи што расте наместо да се празни
• Сертификат што истекува за помалку од две недели

Последното звучи тривијално сѐ додека истечен сертификат не ја собори страницата во сабота. Се случува постојано и целосно е спречливо.

Насочете ги предупредувањата таму каде луѓето навистина гледаат

Предупредување што оди на е-адреса што никој не ја чита не е следење. Насочете ги кон каналот каде тимот живее — обично Slack — и осигурете се дека има еден јасно именуван канал, а не пет.

Потоа држете се до дисциплина за обемот. Начинот на кој малите тимови грешат не е премалку предупредувања, туку премногу. Штом луѓето ќе го стишат каналот, го изгубивте целото вложување. Ако предупредување се огласи, а искрениот одговор е „да, тоа се случува понекогаш“, тоа не треба да биде предупредување. Или поправете ја основната нестабилност, или избришете го правилото.

Запишете што да се прави во 2 часот по полноќ

Последното парче не чини ништо. За секое од вашите три најверојатни сценарија — страницата е паднала, плаќањата не поминуваат, базата е недостапна — напишете краток документ со тоа кого да контактирате кај секој добавувач, каде се пристапните податоци, како да се врати поставувањето назад и како да се објави порака за статус.

По половина страница за секое. Вредноста не е во документот; вредноста е во тоа што дежурниот во 2 часот по полноќ не е истата личност што ја изградила линијата за поставување пред осумнаесет месеци и се сеќава како работи.

Реалната основна линија

За мал производ, „доволно добро“ следење е: следење грешки со поврзани верзии, синтетичка проверка на патот што носи пари, четири-пет предупредувања базирани на симптоми што одат во еден Slack канал и една страница со упатства за постапување. Тоа е едно попладне поставување и можеби еден час месечно одржување.

Тоа што го добивате е разликата меѓу тоа да дознаете од вашата инструментација и да дознаете од клиент што веќе одлучил да не се врати.

PNK WORKS гради и одржува веб-производи со следење вградено од првиот ден, а не додадено по првиот испад. Започнете проект.