Zarządzane utrzymanie i wsparcie aplikacji
Utrzymywanie działającego już oprogramowania w ramach Państwa SLA i kolejki zgłoszeń: klasyfikacja, poprawki u źródła, wydania poprawkowe, aktualizacje zależności i platform, reakcja na zagrożenia bezpieczeństwa i obsługa incydentów. Druga i trzecia linia, prowadzone przez inżynierów, którzy także budują, więc powtarzająca się usterka jest naprawiana, a nie restartowana.
Dlaczego to problem partnera
Wsparcie to ta część usługi zarządzanej, którą łatwo sprzedać, a trudno obsadzić. Napływa nierównomiernie, wymaga ludzi, którzy potrafią czytać obcy kod pod presją czasu, a w chwili gdy przydzielają do niego Państwo najlepszych inżynierów, przestają oni być dostępni do pracy, która płaci lepiej. Zwykłą odpowiedzią jest osobny, tańszy poziom, który zamyka zgłoszenia, niczego nie naprawiając, a klient zauważa to w ciągu kwartału.
Nasza odpowiedź jest taka, że wsparcie prowadzą inżynierowie. Mogą zmienić system, a nie tylko go opisać, a to jedyny sposób, by powtarzający się incydent przestał się powtarzać.
Co bierzemy na siebie
Klasyfikacja i diagnoza
Podejmowanie tego, na co pierwsza linia nie umie odpowiedzieć, odtwarzanie problemu i mówienie, co faktycznie jest nie tak, zamiast zamykania go jako niemożliwego do odtworzenia.
Poprawki, które się trzymają
Defekty naprawiane u źródła, z testem regresji napisanym pod całą klasę błędu, a nie pod jedno zgłoszenie, aby ten sam incydent nie wrócił w następnym kwartale.
Wydania i poprawki
Wydania poprawkowe dostarczane przez Państwa pipeline, według Państwa procesu zmian, z zależnościami, wersjami frameworków i środowisk uruchomieniowych utrzymywanymi na bieżąco, zamiast dryfowania ku kryzysowi aktualizacji.
Reakcja na zagrożenia bezpieczeństwa
Opublikowane ostrzeżenie dotyczące czegoś, od czego Państwo zależą, jest bezwarunkowym powodem do aktualizacji, a nie pozycją w backlogu. Śledzimy je, łatamy i mówimy, jakie było narażenie.
Monitoring i incydenty
Obserwowanie istniejących alertów, dodawanie tych, które powinny istnieć, i obsługa incydentów z pisemnym opisem po fakcie: co się stało i co zapobiegnie powtórce.
Drobne zmiany
Stały strumień drobnych usprawnień, który zadowala klienta, a nigdy nie uzasadnia projektu: obsługiwany w ramach tej samej mocy przerobowej, na tych samych zasadach.
Państwa SLA, uczciwie oceniony
Nie publikujemy celów czasu reakcji i rozwiązania, bo liczba wymyślona, zanim ktokolwiek zobaczył Państwa system, nie jest nic warta ani dla Państwa, ani dla Państwa klienta. Zamiast tego czytamy SLA, które już Państwo są winni, mówimy, które jego części możemy rzeczywiście udźwignąć i jakiego pokrycia to wymaga, a następnie zobowiązujemy się do tego na piśmie.
To samo dotyczy obsługi poza godzinami pracy. Gdy współpraca jej wymaga i uzgodniliśmy ją z góry, obsadzają ją osoby zrekrutowane lub przydzielone do tych godzin, a nie budzenie kogoś w nadziei na najlepsze. Pracujemy już w godzinach europejskich, australijskich i pacyficznych USA w innych projektach, więc pytanie brzmi, jakiego okna Państwo potrzebują, a nie czy jest to możliwe.
Przejmowanie systemu, którego nie zbudowaliśmy
To normalna sytuacja. Dotąd dziewięć przejęć, najstarsze napisane w 2008 roku.
Najpierw przegląd bez zmian
Dostajemy dostęp do kodu, infrastruktury i historii zgłoszeń, zanim zaczniemy za cokolwiek odpowiadać, i patrzymy, a nie zmieniamy.
Pisemna lista ryzyk
Co jest kruche, co niezałatane, co nieudokumentowane i co obudzi kogoś w nocy, uporządkowane według wpływu na produkcję. Zostaje u Państwa, niezależnie od tego, czy pójdziemy dalej.
Rozmowa o zakresie obsługi
Czytamy SLA, które są Państwo winni klientowi, i uczciwie mówimy, które części możemy udźwignąć, jakich godzin to wymaga i ile kosztuje, zanim którakolwiek strona cokolwiek podpisze.
Przekazanie, a potem uruchomienie
Określony okres towarzyszenia osobie, która dziś ma wiedzę (shadowing), a potem przejmujemy kolejkę. Jeśli nikt już tej wiedzy nie ma, zaczynamy od przeglądu ryzyk.
Pod Państwa nazwą, jeśli tak ustalono
Wsparcie jest zwykle najbardziej widoczną częścią usługi zarządzanej, więc to w nim model white-label ma największe znaczenie. Nasi inżynierowie mogą pracować ze skrzynek pocztowych i kont, które Państwo wydadzą, odpowiadać w Państwa systemie zgłoszeń i pisać raporty o incydentach, które Państwo przekazują bez zmian; Państwa klient przez cały czas ma do czynienia z Państwem. Tworzenie oprogramowania w modelu white-label opisuje, jak się to organizuje, i dotyczy wsparcia dokładnie tak samo.
Jak wyceniamy wsparcie
Za osobę, miesięcznie, więc Państwa własny koszt jest przewidywalny i mogą Państwo na jego podstawie wycenić umowę wsparcia dla klienta. Wszyscy rejestrują czas w naszym własnym portalu, godziny widzą Państwo przez cały miesiąc, a te same dane tworzą fakturę, więc jest jeden zapis, z którym obie strony się uzgadniają.
Gdy wsparcie funkcjonuje obok nowego rozwoju, oba zwykle tworzą jeden delivery pod, a nie dwie umowy, więc spokojne tygodnie po jednej stronie opłacają gorączkowe tygodnie po drugiej.
Pytania o formy wsparcia
Co obejmuje zarządzane wsparcie aplikacji?
Utrzymanie w działaniu oprogramowania, które już pracuje na produkcji: przyjmowanie i klasyfikowanie zgłoszeń z kolejki, odtwarzanie i naprawa błędów, odpowiadanie na pytania techniczne, z którymi nie radzi sobie pierwsza linia, wydawanie wersji poprawkowych, aktualizowanie zależności i wersji platform, obserwowanie alertów i obsługa incydentów, gdy coś się psuje. To praca drugiej i trzeciej linii wsparcia; Państwa pierwsza linia pozostaje tam, gdzie jest.
Czy pracują Państwo według naszego SLA?
Tak. Nie publikujemy celów czasu reakcji i rozwiązania, ponieważ liczba wymyślona, zanim poznamy Państwa system, nic nie jest warta. Czytamy SLA, które już Państwo zobowiązują się spełniać wobec swojego klienta, uczciwie mówimy, które jego części możemy objąć i jakiego pokrycia by to wymagało, a następnie zobowiązujemy się do tego na piśmie.
Czy zapewniają Państwo wsparcie poza godzinami pracy lub dyżury?
Tak. Wsparcie poza godzinami pracy i dyżury są uzgadniane z góry, zapisywane w warunkach wsparcia i obsadzane przez osoby, których godziny pracy im odpowiadają, więc incydent w nocy trafia do kogoś na zmianie, a nie do kogoś obudzonego.
Czy mogą Państwo wspierać system, którego nie zbudowali?
To normalna sytuacja. Dotąd przejęliśmy dziewięć takich systemów, najstarszy napisano w 2008 roku. Wsparcie odziedziczonego systemu zaczyna się od przeglądu w trybie tylko do odczytu i pisemnej listy ryzyk uporządkowanej według wpływu na produkcję, więc pierwsze tygodnie służą zrozumieniu, za co faktycznie Państwo odpowiadają, a nie zgadywaniu pod presją.
Czy te same osoby, które wspierają system, będą go też zmieniać?
Tak, i właśnie o to chodzi. Inżynierowie na wsparciu są inżynierami, a nie osobnym poziomem zamykającym zgłoszenia, więc powtarzający się incydent można naprawić u źródła, zamiast restartować go co poniedziałek. Jeśli mają Państwo u nas zarówno nurt rozwoju, jak i nurt wsparcia, oba korzystają ze wspólnych przeglądów kodu i decyzji architektonicznych.
Jak wyceniane jest wsparcie?
Za osobę, miesięcznie, więc Państwa koszt jest przewidywalny i mogą Państwo na tej podstawie wycenić kontrakt wsparcia dla własnego klienta. Godziny są rejestrowane w naszym portalu i widoczne dla Państwa przez cały miesiąc, a te same dane tworzą fakturę, więc obie strony mają jedno źródło.
Mają Państwo systemy, które trzeba utrzymać w działaniu?
Prosimy o informację o tym, jakie to systemy, co obiecuje Państwa SLA i gdzie wsparcie obecnie zawodzi. Przeczytamy to i powiemy, które części możemy udźwignąć, także te, których nie możemy.