Sprinty modernizacyjne
Krótkie, konkretne działanie, które naprawia w infrastrukturze to, co realnie Cię kosztuje, bez wchodzenia w projekt na wiele miesięcy.
Po co jest sprint
Większość problemów z infrastrukturą nie jest ciekawa. To zadanie backupu, które po cichu nie działa od czasu zmiany hasła, dashboard monitoringu, którego nikt nie otworzył od roku, środowisko testowe z projektu zakończonego w 2022 roku, wciąż generujące rachunek co miesiąc.
Żadna z tych rzeczy nie uzasadnia dużego projektu. Wszystkie po cichu kosztują i wszystkie się kumulują. Sprint modernizacyjny istnieje po to, żeby uporządkować te zaległości w określonym czasie, bez cyklu ofertowania, komitetu sterującego i półrocznego harmonogramu.
Format jest celowo niewielki. Wiesz z grubsza, ile kosztuje, zanim się zacznie, dostajesz spisany rejestr zmian i po jego zakończeniu nie jesteś do niczego zobowiązany.
Co zwykle się znajduje
Ustalenia bywają bardziej przewidywalne, niż klienci się spodziewają. W większości środowisk, które oglądamy, występuje jakaś wersja poniższych problemów.
Backupy, których nikt nigdy nie odtworzył. Działają, raportują sukces, a nikt nie sprawdził, czy powstały plik faktycznie odbuduje system. To najczęstsze poważne ustalenie.
Alerty, których nie ma albo których nikt nie czyta. Albo nic nie alarmuje o rzeczach, które się psują, albo jest tego tyle, że zespół to odfiltrowuje. Oba warianty zawodzą tak samo i w tym samym momencie.
Zasoby bez właściciela. Instancje działające dla usługi, która została wyłączona, wolumeny dyskowe niepodpięte do niczego, środowiska zduplikowane na potrzeby projektu i nigdy nieposprzątane.
Dostępy, które przestały mieć uzasadnienie. Poświadczenia byłych pracowników, klucze API z uprawnieniami znacznie szerszymi, niż integracja potrzebuje, i konta współdzielone, których nikt nie chce zmieniać, bo nie wiadomo, co się wtedy zepsuje.
Środowiska po okresie wsparcia. System operacyjny albo wersja języka, które nie dostają już poprawek bezpieczeństwa, zwykle zostawione w spokoju, bo aktualizacja budzi obawy, a testów brak.
Kolejność znaczy więcej niż liczba napraw
Pokusa przy krótkim zleceniu jest taka, żeby naprawić jak najwięcej. To optymalizowanie nie tego, co trzeba.
Pracujemy w kolejności konsekwencji, co oznacza, że nudne pozycje dotyczące stabilności idą przed widocznymi usprawnieniami. Doprowadzenie do przetestowanego odtwarzania danych daje mniej satysfakcji niż obcięcie miesięcznego rachunku, ale jeśli sprint zostanie skrócony, to właśnie odtwarzania będziesz potrzebować. Optymalizacja kosztów jest naprawdę wartościowa, ale jednocześnie to ta pozycja, która może poczekać miesiąc bez żadnej szkody.
Ta kolejność bywa rozczarowaniem dla osób, które chciały najpierw zobaczyć kwotę oszczędności. Wolimy odbyć tę rozmowę na początku niż po incydencie. Zwykle zresztą jedno wychodzi przy okazji drugiego: przy porządkowaniu środowiska na potrzeby monitoringu i tak trafia się na zasoby, za które nikt świadomie nie płaci.
Czego sprint nie naprawi
Warto jasno powiedzieć, gdzie leżą granice tego formatu, bo krótkie zlecenie łatwo przereklamować.
Sprint nie przeprojektuje architektury systemu. Jeśli problemem jest sam sposób zaprojektowania systemu (jedna baza danych, o którą wszystko się bije, albo monolit, którego nie da się wdrożyć bez uzgodnień między czterema zespołami), kilka tygodni pracy nad infrastrukturą sprawi, że system będzie stabilniejszy i tańszy w utrzymaniu, ale architektura po tym czasie pozostanie ta sama. To osobna praca o innym charakterze i innej skali.
Sprint nie zastąpi też bieżącej opieki nad środowiskiem. Możemy wdrożyć monitoring, ale ktoś musi reagować, kiedy się odezwie. Możemy doprowadzić backupy do stanu, w którym są sprawdzone, ale to sprawdzenie trzeba powtarzać. Jeśli nie ma komu tego przekazać, sensowniejsza rozmowa dotyczy stałego utrzymania, a nie jednorazowego działania.
Co zostaje po sprincie
Konkretnym efektem są same zmiany, ale najdłużej służy zwykle dokumentacja.
Bardzo niewiele zespołów ma rzetelny, spisany opis własnej infrastruktury. Istnieje on w głowach jednej czy dwóch osób oraz w konfiguracji, która oddaliła się od pierwotnych założeń. Powstanie takiego opisu to spora część wartości sprintu, bo dzięki niemu kolejna decyzja (migrować, optymalizować czy zostawić) staje się czymś, co da się przemyśleć, zamiast zgadywać.
Dostajesz też uczciwą listę tego, czego nie naprawiliśmy. Ta lista jest naturalnym punktem wyjścia, jeśli zdecydujesz się pójść dalej.
Co dostajesz
Lista ustaleń uporządkowana według skutków
Wszystko, co znajdziemy, ułożone według tego, ile kosztowałoby Cię, gdyby zawiodło jutro. Ani brakujący backup, ani wygasły certyfikat nie wylądują na czwartej stronie raportu.
Backupy, które zostały odtworzone
Backup, którego nikt nie testował, jest nadzieją, a nie zabezpieczeniem. Sprawdzamy odtwarzanie, faktycznie przywracając dane, i zapisujemy, ile to zajęło.
Monitoring i alerty
Metryki, logi i alerty tam, gdzie jest to potrzebne, ustawione tak, żeby alert coś znaczył. Ciągły szum uczy ludzi ignorowania również tego jednego ważnego alertu.
Wdrożone poprawki bezpieczeństwa
Otwarte porty, nieaktualne poświadczenia, niezałatane środowiska uruchomieniowe, uprawnienia nadane lata temu komuś, kto już nie pracuje. Mało efektowna lista, z której bierze się większość incydentów.
Obniżenie kosztów z konkretnymi liczbami
Przewymiarowane instancje, zapomniane środowiska, wolumeny dyskowe niepodpięte do niczego, a rozliczane co miesiąc. Raportujemy, co zmieniliśmy i ile to oszczędza.
Dokumentacja stanu faktycznego
Spisany opis tego, jak infrastruktura jest naprawdę skonfigurowana. Często najbardziej użyteczny efekt całego sprintu.
Jak pracujemy
- 01
Dostęp i audyt
Dostajemy dostęp do odczytu środowiska i pierwsze dni spędzamy na zrozumieniu, co tam jest, łącznie z elementami, których nie ma na żadnym schemacie.
- 02
Wspólne ustalenie zakresu
Przynosimy listę ustaleń, a Ty decydujesz, co wchodzi do sprintu. Część spraw jest pilna, część kosmetyczna i to Ty wyznaczasz tę granicę.
- 03
Naprawy w kolejności ryzyka
Pracujemy według priorytetów, więc jeśli sprint skończy się wcześniej, najważniejsze rzeczy są już zrobione. Backupy i monitoring zwykle wyprzedzają optymalizację.
- 04
Weryfikacja w realnych warunkach
Zmiany sprawdzamy pod faktycznym obciążeniem i na realnych scenariuszach awarii, zamiast zakładać, że działają. Odtwarzanie danych wykonujemy, a nie tylko konfigurujemy.
- 05
Przekazanie z planem na dalej
Dostajesz dokumentację, rejestr zmian i uczciwą listę tego, czego nie zdążyliśmy zrobić, wraz z oceną, jak bardzo to pilne.
Narzędzia i technologie
Tam, gdzie istnieje dobre narzędzie open source, wybieramy je zamiast zamkniętego. Bez uzależnienia od jednego dostawcy i z kosztami, które da się przewidzieć.
- OpenTofu
- Terraform
- Docker
- Kubernetes
- PostgreSQL
- pgBackRest
- Wazuh
- Grafana
- Prometheus
- AWS
- Microsoft Azure
- Google Cloud
Najczęściej zadawane pytania
Powiązane realizacje
Pozostałe usługi w tej kategorii
Migracje do chmury bez przestojów
Są systemy, których nie da się wyłączyć na weekend. Przenosimy je tak, żeby przez cały czas obsługiwały klientów, z możliwością wycofania na każdym kroku.
Migracje inkrementacyjne
Nie wszystko trzeba przenosić naraz. Migrujemy system po systemie, zaczynając od tego, co najbardziej boli, więc efekty widzisz na długo przed końcem projektu.
Rozwiązania serverless i model scale-to-zero
Twój kod uruchamia się wtedy, kiedy jest potrzebny, i nic nie kosztuje, kiedy nie jest. Przy nierównym ruchu zmienia to rachunek ekonomiczny utrzymania systemu.
Przeczytaj opinie firm, które nam zaufały
Dostarczone znacznie wcześniej niż termin.
Indywidualne podejście ZanReal jest imponujące.
Wiedza i intuicja biznesowa czynią ich wartościowym partnerem.
Szybkie rozwiązania, które obniżyły koszty o 99%.
+20% dostarczalności dla naszych kampanii e-mail.
Najnowsze
Poradniki techniczne, bezpieczeństwo i nasze doświadczenia z budowania rozwiązań AI.
Ciekawi Cię, co dalej?
Zobacz wszystkie postyInfrastruktura wymaga uwagi, ale projekt na pół roku to za dużo?
Napisz do nasNapisz, co w Twoim środowisku martwi Cię najbardziej, a zaproponujemy zakres sprintu, zaczynając od spraw o największym ryzyku.
Nie nadążasz za zmianami w świecie AI?
Pozwól, że weźmiemy to na siebie. Co tydzień destylujemy najważniejsze wydarzenia ze świata AI w skupiony, 5-minutowy przegląd — żebyś był na bieżąco bez szumu.
Dowiedz się więcej