Konfiguracja narzędzia do sprawdzania DR dla arkusza i zadania cron

Gdzie ta konfiguracja może zawieść

Cisza to zwykle objaw awarii. Zadanie cron, które zwraca błąd, wygląda tak samo jak to, które zadziałało.

Sprawdź kod HTTP. 401 oznacza, że klucz jest nieprawidłowy lub go brakuje, a 402 oznacza, że zabrakło kredytów, więc alertuj w obu przypadkach i napraw problem przed wydaniem raportu w kolejnym miesiącu.

Pamiętaj również, że paginacja jest ograniczona do 50 000 wierszy, a bulk_dr obsługuje do 2000 domen w jednym wywołaniu. Dłuższe listy wymagają podziału na fragmenty, co oznacza jedno dodatkowe pętlowanie i koszt jednego kredytu za fragment.

Przetestuj ręcznie najpierw. Uruchom polecenie cron w terminalu, przeczytaj plik logu i sprawdź, czy saldo spadło dokładnie o oczekiwany koszt. Następnie zobacz jak liczby porównują się z planem pakietowym i zdecyduj, jak często uruchamiać to zadanie.

Wersjonuj swoją listę domen. Przechowuj plik w repozytorium lub wspólnym folderze z historią, aby gdy liczba zmieni się w marcu, móc sprawdzić, czy lista również uległa zmianie. Dodaj kolumnę z notatkami dla domen dodanych celowo, np. nowego konkurenta lub klienta, który dołączył w danym miesiącu. Traktuj listę jako dane posiadające właściciela, ponieważ najtańszym błędem jest ten, który zauważysz w porównaniu wersji.

Podział długiej listy na fragmenty

Długie listy to moment, w którym schludna konfiguracja napotyka swoje granice. Wywołanie zbiorcze obsługuje do 2000 domen, więc lista 5000 domen wymaga trzech żądań, a podział musi nastąpić przed pierwszym wywołaniem.

Podziel według stabilnej reguły, np. posortowanej kolejności kolumny domen. Dzięki temu ta sama domena trafi do tego samego fragmentu każdego miesiąca, a porównanie będzie poprawne.

Listy powyżej 2000 wierszy

Zapisz każdy fragment do arkusza jako osobny blok, z numerem fragmentu w pierwszej kolumnie. Nieudany fragment będzie wtedy łatwy do zlokalizowania.

Każdy fragment kosztuje jeden kredyt, więc lista 5000 wierszy to 3 kredyty za uruchomienie, co daje $0.0003. Narzędzie do sprawdzania DR jest tak przydatne, jak lista, którą odczytuje, więc utrzymuj tę listę w czystości.

Jeśli lista przekroczy 5000 wierszy, przemyśl układ samego arkusza. Karta na miesiąc utrzyma czytelność każdego uruchomienia, gdy wiersze się zsumują.

Ponowne uruchomienie jednego nieudanego fragmentu

Jeśli drugi fragment zwróci błąd, uruchom ponownie tylko drugi fragment. Ponowne uruchomienie całej listy zużyje kredyty na wiersze, które już zostały zwrócone.

Zaloguj numer fragmentu wraz z kodem statusu, aby ponowne uruchomienie było jedną linią w logu, a nie poszukiwaniem w arkuszu.

Utrzymanie stabilności mapy fragmentów

Jeśli zmieni się kolejność listy domen, fragmenty się przesuną, a porównanie miesięczne zostanie zaburzony. Sortuj listę przed jej podziałem za każdym razem.

Przechowuj mapę fragmentów obok listy.

Prosty test: wybierz dowolny fragment i przelicz jego wiersze względem listy. Niedopasowanie oznacza, że mapa uległa przesunięciu, co taniej jest znaleźć w arkuszu niż w raporcie.

Co powinna zawierać przydatna linia dziennika miesięcznego

Dziennik, który tylko mówi ok, nie jest wielkim dziennikiem. Każde uruchomienie powinno zapisywać jedną linię, którą zmęczona osoba może przeczytać w dziesięć sekund: datę, fragment, status, zużyte kredyty i saldo po wywołaniu.

Hipotetycznie: linia pokazująca czwarty fragment, status 200, jeden zużyty kredyt i saldo po wywołaniu odpowiada na większość pytań miesiąc później bez otwierania odpowiedzi.

Pola warte zalogowania

Zaloguj datę, nazwę listy, numer fragmentu, kod statusu, pobrane kredyty i saldo po wywołaniu. Te sześć pól pokrywa większość pytań miesiąc później.

Dodaj notatkę tekstową tylko wtedy, gdy osoba zmieniła coś ręcznie.

Alerty, które nie krzyczą wilka

Alertuj natychmiast przy 401 lub 402, ponieważ oba oznaczają, że zadanie nie może wykonać swojej pracy. Ostrzeżenie o niskim saldzie powinno używać wybranego przez Ciebie progu, więc wystrzeli raz i powie, co zrobić dalej.

Wyślij jeden alert na uruchomienie, nie jeden na wiersz, inaczej skrzynka odbiorcza stanie się szumem.

Kto zauważy, gdy zadanie zawiedzie

Miesięczne zadanie działa bez nadzoru. To jest cel automatyzacji, ale też powód, dla którego awaria może pozostać niezauważona przez tygodnie.

Wymień osobę, która czyta log, i osobę, która naprawia zadanie. Dwie imiona są lepsze niż jedno. Wakimia się zdarzają. Runbook wyjaśnia, jak wybrać listę od początku.

Czas poświęcony na konfigurację versus utrzymanie

Pierwsze uruchomienie zajmuje większość godziny, ponieważ klucz, arkusz i testowe wywołanie wymagają uwagi. Po tym rutyna powinna wymagać tylko rzutu okiem każdego miesiąca, a nie przebudowy.

Jeśli utrzymanie rośnie, przyczyną jest zwykle lista. Lista, która zmienia się co tydzień, wymaga właściciela, wersji i reguły dla dodanych elementów.

Uczynienie awarii widoczną

Brakujący wiersz w wyjściu jest łatwiej zauważyć niż cichy błąd. Porównaj liczbę wierszy z długością listy przy każdym uruchomieniu i zapisz ostrzeżenie, gdy się różnią.

Przechowuj to ostrzeżenie w tym samym pliku logu, aby osoba czytająca log widziała je jako pierwsza.

Harmonogramowanie wokół odświeżania indeksu

Indeks odświeża się mniej więcej raz w miesiącu, więc uruchomienie pierwszego dnia miesiąca może odczytać liczby z poprzedniej wersji. Uruchomienie kilka dni później, jak sugerują powyższe kroki, daje czas na zakończenie odświeżania.

Wybierz ten sam dzień każdego miesiąca, aby seria pozostała porównywalna, i zapisz ten dzień w komentarzu do linii cron.

Kiedy przestać automatyzować

Zadanie uruchamiane raz na kwartał może nie uzasadniać linii cron. Arkusz i przypomnienie kalendarzowe mogą wystarczyć, a pół-zautomatyzowana procedura jest gorsza niż jasna procedura ręczna.

Zautomatyzuj, gdy te same kroki działały czysto przez kilka cykli z rzędu.