Bank? System sterowania farmą paneli fotowoltaicznych? A może największy w Polsce punkt wymiany ruchu internetowego? Co wspólnego mają te systemy?Podczas tej prezentacji chciałbym podzielić się z Wami moim przemyśleniami oraz doświadczeniem, które zdobyłem podczas rozwijania i utrzymywania aplikacji od których wymaga się, aby były niezawodne.

1. Kamil Grabowski
"Porażka nie wchodzi w grę,
czyli o niezawodności"[PL]
2018-05-09
@_y3ti

2. Kilka słów o mnie:
• Rebased: DevOps (2015-)
• Inteligo/PKO BP: DevOps (2013-2015)
• PLIX: Developer/DevOps (2007-2013)
• MKS: Developer (2007)
• Freelancer: Developer (2002-2007)

3. Rzeczy się psują -takie jest życie.

4. Rzeczy się psują -takie jest życie,
ale da się tym zarządzać!

5. Jeśli możesz to zmierzyć, to możesz tym zarządzać.
Peter Drucker
“

6. Jak mierzy się niezawodność?
• SLA- Service Level Agreement
• SLI - Service Level Indicator
• SLO - Service Level Objective

7. W jaki sposób możemy zwiększyć
niezawodność?

8. Komunikacja w zespole
• Gramy w jednym zespole (zakończyć odwieczną wojnę admin vs developer)
• Zakładamy, że wszyscy mamy dobre intencje
• Krytykujemy rozwiązania, a nie ludzi
• Koncentrujemy się na szukaniu rozwiązań, a nie winnych
• Szanujemy czas naszych kolegów i koleżanek
• Po prostu be nice :)

9. Karta projektu (README.md)
• Podstawowe informacje o projekcie (aktualizowanie!)
• Właściciel projektu / Developerzy / PM
• Prosta i testowalna instrukcja jak zbudować i uruchomić aplikację
• Używany stos technologiczny (system, wersja nodejs, wersja npmjs/yarn)
• Konfiguracja (parametryzacja, credentials)
• Wymagana konfiguracja sieciowa (czy korzystamy z DNS?)
• Zarządzanie projektem (czy używamy github issues, czy zew. system)
• Szablony do GitHub Issues i Pull Requests

10. Development
• Formatowanie kodu (wcięcia, charset itp.) / EditorConfig
• Narzędzia do statycznej analizy kodu / lintery
• Testy + Code Coverage
• Skanery bezpieczeństwa
• Continuous Integration
• Code review
• GitHub - Protected Branches

11. Zależności w projekcie
• Wszystkie wymagane biblioteki są zdefiniowane w jednym pliku ( packages.json )
• Każda biblioteka jest zdefiniowana wraz z wymaganą wersją
• Instalacja bibliotek jest prosta, jedna komenda ( npm install )
• Aplikacja nie jest zależna od bibliotek zainstalowanych dla całego systemu
• Wszystkie zewnętrzne narzędzia (np. curl ) powinny być dostarczone razem z
Aplikacją

12. Konfiguracja
• Brak podziału na grupy typu: production, staging, qa
• Konfiguracja jest oddzielona od kodu Aplikacji
• Konfiguracja jest dostarczana przez środowisko uruchomieniowe
• Zmienne środowiskowe
• Podłączenie (mount) lub nadpisanie pliku konfiguracyjnego
• Aplikacja pobiera konfigurację przy starcie z zewnętrznego systemu
• Każdy parametr posiada domyślną wartość (jeśli to możliwe)

13. Testowanie konfiguracji
• Commandlinowe narzędzie do sprawdzania poprawności konfiguracji
• Czy wszystkie parametry posiadają poprawną wartość
• Czy mogę nawiązać połączenie z zewnętrznymi usługami
• Nie wymaga uruchomienia przetwarzania danych/requestów

14. Healthchecks
• GET /healthchecks/liveness
• Czy aplikacja żyje i odpowiada na requesty
• GET /healthchecks/readiness
• Czy aplikacja może otrzymywać nowe requesty
• GET /healthchecks/corectness
• Aplikacja jest poprawnie skonfigurowana
• Możemy nawiązać połączenie z zewnętrznymi usługami

15. Metryki
• GET /metrics
• dane telemetryczne w plain-text
• borgmon, prometheus
• biblioteki klienckie dla wielu popularnych platform (w tym nodejs )
• różne typy danych: counter, gauge, histogram, summary

16. Jakie metryki wybrać?
• USE (Utilization, Saturation, Errors)
• RED (Rate, Error, Duration)
• The Four Golden Signals by Google SRE
• Latency
• Traffic
• Errors
• Saturation

17. # TYPE nodejs_heap_space_size_total_bytes gauge
nodejs_heap_space_size_total_bytes{space="new"} 1048576 1497945862862
nodejs_heap_space_size_total_bytes{space="old"} 9818112 1497945862862
nodejs_heap_space_size_total_bytes{space="code"} 3784704 1497945862862
nodejs_heap_space_size_total_bytes{space="map"} 1069056 1497945862862
nodejs_heap_space_size_total_bytes{space="large_object"} 0 1497945862862
1
2
3
4
5
6

18. # TYPE http_request_duration_ms histogram
http_request_duration_ms_bucket{le="10",code="200",route="/",method="GET"} 58
http_request_duration_ms_bucket{le="100",code="200",route="/",method="GET"} 1476
http_request_duration_ms_bucket{le="250",code="200",route="/",method="GET"} 3001
http_request_duration_ms_bucket{le="500",code="200",route="/",method="GET"} 1001
http_request_duration_ms_bucket{le="+Inf",code="200",route="/",method="GET"} 1
1
2
3
4
5
6

19. Logi
• Logi są ciągłym, niebuforowanym strumieniem danych bez początku i końca
• STDOUT / STDERR
• Nie implementować własnych mechanizmów rotowania logów
• Format łatwo parsowalny (np. json) lub CSV
• Jeden wpis = jedna linia
• Jeśli wpisów będzie wiele, dodajemy unikalny identyfikator (np. request_id)

20. Co warto logować?
• Błędy (Message, file, line)
• HTTP Method: GET, POST, HEAD itd.
• Request np. /foo/bar?foo=bar
• Czas obsłużenia requestu (duration)
• Czas dodania wpisu (UTC, ISO 8601 Notation)
• Informacje o kliencie (identyfikator, źródłowy adres ip)
• Status (OK, ERROR)

21. Prawidłowa obsługa sygnałów (Unix signals)
• SIGTERM - poprawne zakończenie działania procesu
• zamknięcie otwartego portu TCP
• zakończenie aktywnych zadań
• SIGHUP - przeładowanie konfiguracji, opcjonalnie ponowne nawiązanie połączenia z
zewnętrznymi usługami
• SIGUSR1 , SIGUSR2 - opcjonalnie, zmniejszenie/zwiększenie poziomu logów

22. Deployment
• Jeśli to możliwe to wdrażamy Continuous Deployment
• Release powoduje utworzenie artefaktu (zip, tgz, docker image)
• Artefakty przechowuj poza serwerem CI (np. S3 lub docker registry)
• Release notes, changelog (zmiany w konfiguracji, zależności w postaci zewnętrznych
usług)
• Zespół programistów powinien być częścią zespołu wdrożeniowego
• Często najwięcej informacji posiada osoba, która doprowadziła do powstania danego
zdarzenia. Skorzystaj z pomocy tej osoby

23. Optymalizacja kodu
• Na początku projektu nie przejmuj się wydajnością (good enough)
• Najpierw prawidłowo zaimplementuj metryki i logi
• Jeśli optymalizujesz to zawsze mierz i porównuj wyniki
• Od samego początku narzucaj sobie limity:
• Zasoby: CPU, RAM, I/O, Sieć
• Pula połączeń (baza danych)
• Obsługa reuqestu np. poniżej 40ms

24. Dodanie nowych technologii do stosu projektu
• Jaka będzie wartość dodana? Jaki problem rozwiążemy?
• Czy możemy użyć już wykorzystywaną w projekcie technologię?
• Czy weźmiemy za nią odpowiedzialność (on-call)?
• Dobrze, jeśli 2-3 osoby z zespołu znają tę technologię lub mają chęć jej poznania
• Alternatywy?
• Popularność, Narzędzia, Support

27. W informatyce nie jest istotne to
CZY
coś działa wolno lub szybko...

28. ...istotne jest to
DLACZEGO
coś działa wolno lub szybko!

29. Pytania?

30. See you next
month at
WarsawJS