Zarządzanie i skalowanie

Eksploatacja i rozwój rozwiązań cyfrowych: OTOKO® wspiera Państwa w utrzymaniu, zarządzaniu technicznym i skalowaniu systemów.

Aktualizacje bezpieczeństwa, nowe wymagania i awarie nie kończą się wraz z odbiorem.

Przejęcie z analizą kodu, inwentarzem zależności, dokumentacją i transferem wiedzy Monitoring z użyciem narzędzi Prometheus, Grafana i OpenTelemetry, alarmowanie według poziomu krytyczności Zarządzanie incydentami i problemami zgodnie z ITIL w narzędziu Jira Service Management Aktualizacje bezpieczeństwa i utrzymanie zależności za pomocą narzędzia Renovate, weryfikacja pod kątem znanych podatności Regularne raporty dotyczące dostępności, incydentów i otwartych ryzyk

Katalog usług ze ścieżkami reakcji i zakresami odpowiedzialności Monitoring z alarmowaniem i dashboardami Raporty z eksploatacji obejmujące incydenty i ryzyka

Repozytorium, licencje i dostępy techniczne Dokumentacja, znane incydenty i obecni dostawcy usług Oczekiwane godziny serwisowe i krytyczność biznesowa

Aplikacja specjalistyczna opracowana wewnętrznie ma zostać przekazana zespołowi zewnętrznemu. Po analizie kodu i uzyskaniu odtwarzalnego buildu najpierw sprawdzane są monitoring i przywracanie danych. Następnie rozpoczyna się utrzymanie z uzgodnionymi godzinami serwisowymi i listą zaszłości uszeregowanych według priorytetów.

Jira Service Management Grafana Prometheus OpenTelemetry Renovate

Zanim przejmiemy odpowiedzialność, sprawdzamy dostęp do kodu, prawa użytkowania, zależności oraz możliwość samodzielnego zbudowania wersji. Wspólnie spisujemy znane problemy, wiedzę eksploatacyjną i krytyczne procesy. Samo poprawne uruchomienie aplikacji nie wystarczy: trzeba też wyjaśnić kwestie kopii zapasowych, przywracania danych i odpowiedzialności za usługi zewnętrzne. Efektem przejęcia jest zakres usług z otwartymi ryzykami i działaniami uszeregowanymi według priorytetów. Zaszłości, nad którymi nie da się zapanować, nie są po cichu włączane do ryczałtowego zobowiązania. Jeśli najpierw konieczna jest stabilizacja, opisujemy ją jako osobny pakiet prac.

Działający serwer niewiele mówi o tym, czy użytkownicy mogą wykonywać swoją pracę. Dlatego kierujemy monitoring również na ważne operacje aplikacji i interfejsy. Powiadomienia są klasyfikowane według ich skutków; każdy alarm wymaga odbiorcy i sensownego pierwszego kroku. Godziny wsparcia, docelowe czasy reakcji i ścieżki eskalacji są ustalane w umowie. Czas reakcji nie oznacza gwarantowanego czasu rozwiązania. W przypadku poważnych incydentów ustalamy zasady komunikacji, uprawnienia decyzyjne oraz współpracę z Państwa dostawcą infrastruktury lub oprogramowania.

Aktualizacje są oceniane pod kątem ryzyka, pilności i kompatybilności. Utrzymujemy widoczność zależności, sprawdzamy zmiany w odpowiednim środowisku i planujemy dostarczenie ze ścieżką powrotu. Powtarzające się awarie są analizowane pod kątem przyczyn, aby eksploatacja nie sprowadzała się stale do tych samych napraw. Regularne raporty łączą incydenty, ryzyka techniczne i nadchodzące decyzje. Drobne usprawnienia mogą być realizowane w uzgodnionym zakresie; większe rozszerzenia funkcjonalne są priorytetyzowane osobno. Z myślą o ewentualnym późniejszym przekazaniu Państwa zespołowi na bieżąco dokumentujemy wiedzę i dostępy.

Aplikacja może być dostępna, a mimo to nie przetwarzać zamówień. Dlatego wybieramy punkty pomiarowe dla istotnych procesów użytkownika i rozróżniamy dostępność, poprawne przetwarzanie oraz czas odpowiedzi. Cel usługowy wymaga okresu pomiaru, źródła danych i zasad postępowania w przypadku brakujących pomiarów. Dopiero wtedy można w sposób możliwy do zweryfikowania ocenić, czy uzgodniony stan został osiągnięty. Pozostałe odchylenie od celu można wykorzystać jako budżet błędów, aby wyważyć stabilizację i dalszy rozwój. Wspólnie ustalamy, jakie konsekwencje ma jego przekroczenie. Nie zastępuje to ani umownych uzgodnień dotyczących usług, ani oceny pojedynczego poważnego incydentu. Dashboardy i alarmowanie mają wspierać decyzje: kto reaguje, jaka diagnostyka następuje i kiedy trzeba poinformować osoby odpowiedzialne merytorycznie?

Pomyślnie zakończone tworzenie kopii zapasowej nie dowodzi jeszcze, że dane da się przywrócić. Ustalamy, jaka maksymalna utrata danych byłaby akceptowalna i jak długo może trwać przestój. Z tego wynikają wymagania dotyczące częstotliwości tworzenia kopii, okresu ich przechowywania i ponownego uruchomienia. Do aplikacji oprócz bazy danych często należą pliki, konfiguracja, klucze i usługi zewnętrzne; jeśli brakuje jednego z elementów, technicznie odczytywalna kopia zapasowa może mimo to okazać się bezużyteczna. Ćwiczenia z przywracania sprawdzają uzgodniony proces w odpowiednim środowisku. Dokumentowane są przy tym czas trwania, wymagane dostępy, kroki manualne i merytoryczna weryfikacja danych. Przywrócenie danych pojedynczego dzierżawcy lub przypadkowo usuniętego rekordu może wymagać innej ścieżki niż całkowita awaria. Wyniki przekładają się na konkretne usprawnienia. Stwierdzone luki nazywamy wprost, zamiast przedstawiać niesprawdzoną wartość docelową jako zagwarantowaną zdolność.

Zgłoszenie dotyczące podatnej biblioteki jest oceniane w kontekście aplikacji: która wersja jest wykorzystywana, czy podatna funkcja jest osiągalna i jakie środki ochrony istnieją? Pilność i techniczne ryzyko zmiany rozpatrujemy łącznie. Dla aktualizacji niemożliwych do natychmiastowego wdrożenia potrzebne są udokumentowane środki tymczasowe oraz termin ponownej oceny. Nowe wersje przechodzą odpowiednie testy i uzgodnione wdrożenie. Po powtarzających się lub poważnych awariach badamy przyczynę, sposób wykrycia i reakcję. Powstają z tego działania uszeregowane według priorytetów, z przypisanymi osobami odpowiedzialnymi, a nie tylko zamknięte zgłoszenie (ticket). Dokumentacja, runbooki i zestawienia dostępów są aktualizowane na bieżąco. Przygotowujemy też późniejsze przekazanie Państwa zespołowi lub innemu dostawcy usług: wraz z repozytorium, instrukcją budowania, otwartymi ryzykami i uporządkowanym przekazaniem dostępów. W dłuższej perspektywie usługa jest trwała, gdy wiedza pozostaje przejrzysta.

Środowisko aplikacyjne, wymagania, ryzyka Dział biznesowy, IT, bezpieczeństwo informacji, architekt oprogramowania OTOKO® Ocenione przedsięwzięcia, inwentaryzacja, wymagania bezpieczeństwa i eksploatacji

Architektura, technologia, model eksploatacji Dział biznesowy, architektura, ochrona danych, bezpieczeństwo informacji Architektura docelowa, model zagrożeń, strategia testów, model eksploatacji, kamienie milowe