DevOps DLA BYSTRZAKÓW

SPIS TREŚCI

O autorce

Dedykacja

Podziękowania

Przedmowa

Wstęp

O tej książce
Niezbyt rozsądne założenia
Ikony wykorzystane w książce
Co dalej?

Część 1: Czym jest DevOps

Rozdział 1: Wprowadzenie do DevOps

Czym jest DevOps?
DevOps wyewoluował z Agile’a
DevOps skupia się na ludziach
U podstaw DevOps leży kultura firmy
Uczysz się, obserwując swój proces i zbierając dane
Przekonanie jest kluczem do przyjęcia DevOps
Małe, przyrostowe zmiany są bezcenne
Korzyści płynące z DevOps
Model CALMS
Rozwiązywanie problemu sprzecznych interesów

Rozdział 2: Projektowanie własnej organizacji

Ocena stanu zdrowia kultury
Wprowadzenie DevOps
Ustalanie wartości DevOps
Zachęcaj do pracy zespołowej
Redukuj strukturę silosową
Stosuj myślenie systemowe
Przyjmuj porażki
Przede wszystkim komunikacja!
Przyjmuj informację zwrotną
Automatyzuj procesy (w razie potrzeby)
Modelowanie kultury organizacyjnej
Unikanie najgorszych elementów kultury świata technologii
Tworzenie własnej wizji
Zachęcanie do wyznawania swoich wartości
Oceny
Nagrody

Rozdział 3: Identyfikacja obszarów marnotrawstwa

Na czym polega siedem rodzajów marnotrawstwa?
Niepotrzebny proces
Czekanie
Zbędny ruch
Koszty wad
Nadprodukcja
Transport
Nadmierne zapasy
Zrozumienie pojęcia marnotrawstwa w DevOps
Usuwanie marnotrawstwa
Odkrywanie wąskich gardeł
Skoncentruj się na wpływie

Rozdział 4: Przekonanie współpracowników do wypróbowania DevOps

Lęk przed zmianą
Przekonanie otoczenia do przejścia na DevOps
Zdobycie wsparcia kadry kierowniczej
Wywołanie narastającej fali zmian w grupie inżynierskiej
Zarządzanie menedżerami średniego szczebla
Przekonywanie uparciuchów
Zrozumienie krzywej akceptacji
Popychanie w kierunku zmian
Reagowanie na głosy sprzeciwu
Poruszanie się nad przepaścią
Pytanie „dlaczego?”

Rozdział 5: Przeprowadzenie pomiaru Twojej organizacji

Mierzenie swoich postępów
Aspekty ilościowe w DevOps
Gromadzenie danych
Opracowanie wewnętrznych studiów przypadku

Część 2: Stworzenie potoku

Rozdział 6: Przyjęcie nowego cyklu życia rozwoju oprogramowania

Zaproszenie wszystkich do stołu
Zmiana procesów: od linii do cyklu
Przesunięcie eksploatacji „w lewo”: myślenie o infrastrukturze
Przesunięcie „w lewo” również wdrożeń
Naśladowanie produkcji poprzez środowisko testowe

Rozdział 7: Planowanie z wyprzedzeniem

Wyjście poza model Agile
Wyzwania związane z prognozowaniem
Identyfikacja wyzwań i ograniczeń projektowych
Gromadzenie wymagań
Projektowanie MVP
Odkrycie problemu, który ma zostać rozwiązany za sprawą Twojego MVP
Identyfikacja klienta
Obserwacja konkurencji
Ustalanie priorytetów w zakresie funkcji
Projektowanie doświadczeń użytkownika
Testowanie hipotezy
Beta czy nie beta?
Określenie klienta przez zaprojektowanie persony
Co to jest persona?
Projektowanie persony

Rozdział 8: Projektowanie funkcji z perspektywy DevOps

Praca nad projektem
Projektowanie pod kątem DevOps
Projektowanie oprogramowania na potrzeby zmian
Ciągłe ulepszanie oprogramowania
Dokumentowanie oprogramowania
Tworzenie architektury kodu pod kątem sześciu zdolności DevOps
Łatwość utrzymania
Skalowalność
Bezpieczeństwo
Użyteczność
Niezawodność
Elastyczność
Dokumentowanie decyzji projektowych
Unikanie pułapek architektonicznych

Rozdział 9: Tworzenie kodu

Komunikowanie się na temat kodu
Inżynieria w zakresie błędów
Pisanie kodu łatwego w utrzymaniu
Testowanie kodu
Debugowanie kodu
Kod logowania
Pisanie niezmiennego kodu
Tworzenie czytelnego kodu
Wzorce programowania
Programowanie obiektowe
Programowanie funkcyjne
Wybór języka
Unikanie antywzorców
Rozwój w kierunku DevOps
Pisanie czystego kodu
Zrozumienie biznesu
Słuchanie innych
Skupianie się na właściwych rzeczach
Pogodzenie się z brakiem komfortu
Ustanowienie dobrych praktyk
Organizowanie kodu źródłowego
Pisanie testów
Dokumentowanie funkcji
Przeglądanie kodu przez współpracowników

Rozdział 10: Automatyzacja testów przed wydaniem

Testowanie nie jest opcjonalne
Automatyzacja testów
Testowanie w różnych środowiskach
Środowisko lokalne
Środowisko deweloperskie
Środowisko badawcze
Środowisko testowe imitujące produkcyjne
Środowisko produkcyjne
Wyjście poza testy jednostkowe
Testy jednostkowe: To żyje!
Testy integracyjne: Czy wszystkie elementy współpracują ze sobą?
Testy regresji: Czy po zmianach kod zachowuje się tak samo?
Testy wizualne: Czy wszystko wygląda tak samo?
Testy wydajności
Ciągłe testowanie

Rozdział 11: Wdrażanie produktu

Wydanie kodu
Ciągła integracja i dostarczanie
Korzyści płynące z CI/CD
Wdrażanie CI/CD
Zarządzanie wdrożeniami
Właściwa automatyzacja
Wersjonowanie
Łagodzenie skutków niepowodzeń
Wycofanie zmian
Naprawa bez cofania zmian
Demokratyzacja wdrożeń
Wybór stylu wdrażania
Blue-green: nie tylko kolor jezior
Kanarek Schrödingera: wdrożenie nie umarło (a może jednak?)
Stopniowe wdrażanie zmian
Przełączanie za pomocą flag funkcji
Monitorowanie systemów
Rozumienie telemetrii
Zapis zachowania
SLA, SLI oraz SLO

Cześć 3: Łączenie cyklu w całość

Rozdział 12: Wdrażanie szybkiej iteracji

Nadawanie priorytetów temu, co ważne
Ważne i pilne
Ważne, niepilne
Pilne, mało ważne
Ani ważne, ani pilne
Zwiększanie prędkości
Poprawa wydajności
Wyeliminowanie doskonałości
Projektowanie małych zespołów
Śledzenie swojej pracy
Zmniejszenie tarcia
Dostosowanie alertów do możliwości poznawczych ludzi

Rozdział 13: Tworzenie pętli informacji zwrotnej w kontekście klienta

Tworzenie procesu przekazywania informacji zwrotnych przez klientów
Tworzenie pętli informacji zwrotnej
Przyjmuj
Analizuj
Komunikuj
Zmieniaj
Zbieranie informacji zwrotnej
Badania satysfakcji
Studia przypadku
„Dogfooding”, czyli wypróbuj to na własnej skórze
Prośba o ciągłą informację zwrotną
Net promoter score (NPS)
Odnalezienie rytmu

Rozdział 14: DevOps nie jest zespołem (wyjąwszy sytuacje, kiedy jest)

Tworzenie zespołów DevOps
Zharmonizowanie zespołów funkcjonalnych
Wyznaczanie do DevOps oddzielnego zespołu
Tworzenie wielofunkcyjnych zespołów produktowych
Przeprowadzanie szybkich (ale nie zbyt szybkich) rozmów kwalifikacyjnych
Podjęcie decyzji o wyborze nazwy stanowiska
Rekrutacja nigdy się nie kończy
Znalezienie właściwych ludzi
Przekazanie wspaniałych kandydatów
Ocena zdolności technicznych
Powrót do białej tablicy
Oferowanie testów domowych
Przegląd kodu
Szybkie zwalnianie
Arogancki palant
Męczennik
Niewydolny pracownik

Rozdział 15: Wzmocnienie pozycji inżynierów

Skalowanie zespołów inżynierskich za pomocą metodyki DevOps
Trzy etapy przedsiębiorstwa
Motywowanie inżynierów
Badania nad motywacją
Motywacja do podejścia DevOps
Niepoleganie na nagrodach zewnętrznych
Autonomia
Mistrzostwo
Poczucie sensu
Spraw, żeby praca była przyjemna
Umożliwienie ludziom wyboru zespołu
Pomiar motywacji

Część 4: Kaizen w praktyce jako sztuka ciągłego doskonalenia

Rozdział 16: Produktywne podejście do niepowodzeń

Szybkie porażki w świecie technologii
Bezpieczna porażka
Kontrola awarii
Akceptowanie błędu ludzkiego (i wyeliminowanie poczucia winy)
Ponoszenie porażek we właściwy sposób
Utrzymanie postawy ukierunkowanej na rozwój
Tworzenie przestrzeni wolności do ponoszenia porażek

Rozdział 17: Przygotowanie się na incydenty

Walka z „błędem człowieka” za pomocą automatyzacji
Skoncentrowanie się na systemach: realistyczna automatyzacja
Używanie narzędzi do automatyzacji w celu uniknięcia problemów z integracją kodu
Obsługiwanie wdrożeń i infrastruktury
Ograniczanie nadmiernego projektowania
Naprzemienne dyżury pod telefonem na ludzkich zasadach
Kiedy dyżury stają się nieludzkie
Ludzkie oczekiwania względem dyżurów
Zarządzanie incydentami
Uczynienie konsekwentności celem
Przyjęcie standardowych procesów
Ustalenie realistycznego budżetu
Ułatwienie reagowania na incydenty
Reagowanie na nieplanowane zakłócenia
Empiryczny pomiar postępu
Średni czas naprawy (MTTR)
Średni czas między awariami (MTBF)
Koszt przypadający na incydent (CPI)

Rozdział 18: Przeprowadzanie przeglądów po incydencie

Wyjście poza analizę przyczyn źródłowych
Przechodzenie przez incydent
Wnioski z przeglądów
Zaplanuj to natychmiast
Zaangażowanie wszystkich pracowników
Brak kozłów ofiarnych
Przegląd osi czasu
Zadawanie trudnych pytań
Uznanie efektu pewności wstecznej
Sporządzanie notatek
Tworzenie planu

Część 5: Narzędzia do praktykowania DevOps

Rozdział 19: Przyjęcie nowych narzędzi

Integracja z otwartym oprogramowaniem
Otwarcie się na innowacje w ramach społeczności
Licencjonowanie otwartego oprogramowania
Decyzja o wyborze otwartego oprogramowania
Przejście na inne języki
Kompilowanie i interpretowanie języków
Paralelizacja i wielowątkowość
Programowanie funkcjonalne
Zarządzanie pamięcią
Roztropne wybieranie języków

Rozdział 20: Zarządzanie rozproszonymi systemami

Praca z monolitami i mikrousługami
Stosowanie architektury monolitycznej na wczesnym etapie projektu
Ewoluowanie w kierunku mikrousług
Projektowanie świetnych interfejsów API
Co znajduje się w API
Koncentracja na spójnym projekcie
Kontenery: oferują znacznie więcej niż maszyny wirtualne
Zrozumienie kontenerów i obrazów
Wdrażanie mikrousług do kontenerów
Porównanie orkiestratorów: harmonizacja ula
Konfiguracja kontenerów
Monitorowanie kontenerów: utrzymuj je przy życiu, dopóki ich nie zabijesz
Zabezpieczanie kontenerów: te skrzynki potrzebują zamka

Rozdział 21: Migracja do chmury

Automatyzacja DevOps w chmurze
Przeniesienie kultury DevOps do chmury
Uczenie się przez przyjęcie
Korzyści z usług w chmurze
Cumulus, cirrus i stal: rodzaje chmur
Chmura publiczna
Chmura prywatna
Chmura hybrydowa
Chmura jako usługa
Infrastruktura jako usługa
Platforma jako usługa
Oprogramowanie jako usługa
Wybór najlepszego dostawcy usług w chmurze
Amazon Web Services (AWS)
Microsoft Azure
Google Cloud Platform (GCP)
Znajdowanie narzędzi i usług w chmurze

Część 6: Dekalogi

Rozdział 22: Dziesięć (plus) powodów, dla których DevOps ma znaczenie

Akceptacja ciągłych zmian
Przyjęcie chmury
Zatrudnianie najlepszych
Utrzymanie konkurencyjności
Rozwiązywanie ludzkich problemów
Stawianie wyzwań przed pracownikami
Niwelowanie różnic
Ponoszenie porażki z wdziękiem
Ciągłe doskonalenie
Automatyzacja trudu
Przyspieszenie dostawy

Rozdział 23: Dziesięć największych pułapek DevOps

Nadanie kulturze niższego priorytetu
Pozostawienie innych w tyle
Zapominanie o dopasowaniu zachęt
Siedzenie cicho
Zapominanie o pomiarach
Mikrozarządzanie
Zbyt wiele zmian w zbyt krótkim czasie
Zły wybór narzędzi
Strach przed porażką
Bycie zbyt rygorystycznym