praktyczna ścieżka do dojrzałości DevOps

każda zwinna metodologia jest daremna bez prawdziwych praktyk DevOps. Hasło było nadużywane w wielu organizacjach. Jeśli powiesz, że masz Dojrzałe zespoły zwinne i masz inżyniera DevOps lub zespół DevOps, którzy prawdopodobnie nie idą w dobrym kierunku. DevOps to kultura, a nie nazwa lub oznaczenie zespołu. Biorąc pod uwagę CMM (Capability Maturity Model), ta próba ma pomóc organizacji dowiedzieć się, na czym polega podróż DevOps i w przyszłości. Dzięki burzy mózgów między zespołami programistów i Ops można ją rozszerzyć i dostosować do potrzeb organizacji.

No number is bad as for as it helps an individual or organization to grow.

zadowolony klient

w przeciwieństwie do CMM, nie jest to model, który musisz udowodnić żadnej organizacji certyfikującej. Jedyny certyfikat otrzymujesz od zadowolonych klientów lub partnerów biznesowych. Jest to model do samodzielnej refleksji i pomocy biznesowi w rozwoju. Celem każdego zespołu IT jest tworzenie wartości poprzez zrównoważoną, przewidywalną dostawę z jakością.

jest to prosty model, który od dewelopera do CxO może zrozumieć i powiązać.

zanim omówię model. Musimy zrozumieć potrzebę tego modelu. Wiele lat temu Melvin Conway w swoim artykule ” How do committees invent?”wymyślił tezę, która stała się sławna jako prawo Conwaya.

każda organizacja, która zaprojektuje system (zdefiniowany szeroko), stworzy projekt, którego struktura jest kopią struktury komunikacji organizacji.

prawo opiera się na rozumowaniu, że aby moduły oprogramowania działały, Wiele osób musi często komunikować się ze sobą. Dlatego struktura interfejsu oprogramowania systemu będzie odzwierciedlać społeczne granice organizacji (organizacji), które go stworzyły, przez które komunikacja jest trudniejsza.

spójrzmy, jak to działa w tworzeniu oprogramowania z rzeczywistym scenariuszem. Radha buduje ekran frontowy, który pokazuje szczegółowe atrybuty produktu. Powiedz, że ten produkt to telefon komórkowy. Kilka typowych szczegółów produktu to kolor, cena, wymiary, oceny itp. Pojawiła się nowa regulacja wyświetlania wartości SAR słuchawki. Ekran, który zaprojektowała, współpracuje z Micro service call. Rozmawiała z Sunilem, który pracuje w zespole danych. Powiedział, że mogą wysyłać dane tylko w płaskich plikach. Istnieje wyraźne rozłączenie między dwoma modułami. Jest to scenariusz, z którym spotyka się każdy zespół IT, jeśli nie wszystkie 100% razy, ale większość razy. To tylko kwestia projektu. Problem jest szerszy. Co jeśli priorytety drugiej drużyny bardzo różnią się od tego, co robi Twoja drużyna? Twoje wymagania mogą być dla nich NAJNIŻSZYM priorytetem, podczas gdy Twoi interesariusze są za tobą.

pierwszym krokiem do pomyślnego wdrożenia DevOps jest otwarcie się na zmiany organizacyjne.

zmiany organizacyjne

omówię 5 poziomów dojrzałości:

  1. początkowy: w tej fazie, zespoły pracują w silosach i nie ma tylko, trzeba oparte współpracy. Na spotkaniu ze wszystkimi zespołami razem, jeśli zapytasz, Kto jest właścicielem „produktu”, nie będziesz miał żadnych rąk podnoszących. Czas wprowadzenia na rynek jest zazwyczaj dłuższy, sięgający miesięcy, a czasem lat. Priorytety są ustalane na poziomie zespołu, ale nie na poziomie produktu. Doprowadzi to do tego, że każdy zespół będzie miał własne priorytety. Ponieważ nie ma zdefiniowanego procesu, każda próba jest jak wynalezienie koła na nowo. Doprowadzi to do problemów z jakością i dłuższych terminów. Zespół wykonuje głównie ręczne wdrożenia i ręczne interwencje. Cóż.. to nie jest zły stan. W ten sposób rozpocznie się większość prac rozwojowych.

2. Powtarzalne: zespoły nadal pracują w silosach. Istnieje pewien poziom automatyzacji w zespole. Kiedy kryzys uderza, zespół określa swój własny proces i podąża za nim aż do jego zakończenia. Tylko dobrą wiadomością jest to, że niektóre z nich mogą stać się powtarzalnymi procesami, gdy kryzys dotknie ponownie.

3. Zdefiniowany: jest to dobry punkt wyjścia do zalążka Kultury DevOps ze scentralizowanym zespołem. Ten zespół rozumie różne technologie, których używają zespoły programistów, a oprzyrządowanie opiera się na aktualnych potrzebach. Będąc scentralizowanym zespołem, nie jest łatwo monitorować, co robi każdy zespół, więc niektóre decyzje pozostawiają zespołom do eksperymentowania. Centralny zespół zazwyczaj składa się z ekspertów, a zespoły programistów będą miały kilka osób z podstawową wiedzą i zrozumieniem.

4. Zarządzanie: ponieważ centralny zespół DevOps rozumie środowisko narzędzi organizacji, testowane jest wiele środowisk i narzędzi. Spójne i powtarzalne procesy są realizowane przez wiele zespołów. Łańcuch narzędzi jest wybierany na podstawie przypadków użycia, a nie osobistych wyborów. Narzędzia do monitorowania wszystkich procesów są wprowadzane i intensywnie wykorzystywane przez zespoły do podejmowania decyzji.

5. Zoptymalizowane:

sukces dobrego lidera jest definiowany nie przez posiadanie zwolenników, ale przez umiejętność tworzenia wielkich liderów.

ostatnim etapem dojrzałości DevOps jest zniknięcie zespołu DevOps. To może wyglądać na intuicyjne. Na tym etapie DevOps jest częścią zespołu rozwoju produktu, a nie oddzielną jednostką. Wykorzystanie infrastruktury jako kodu, kontenerów, orkiestracji itp. osiągnięto wdrożenie zero touch. Teraz, jeśli zadzwonisz do wszystkich, którzy pracują nad produktem i zapytasz, Kto jest właścicielem produktu, będziesz miał pewne ręce podnoszące bez wahania. Dane z narzędzi monitorujących są wykorzystywane do wyboru nowego zestawu narzędzi (w tym infrastruktury, języków programowania, technik). Decyzje są oparte na danych, a nie osobistych preferencjach. Zespół ds. produktu jest gotowy do wdrożenia kodu każdego dnia i o każdej porze. Kochają „wartość biznesową” i traktują ją jak zwierzaka. Wszystko inne jest traktowane jak bydło.

Model Dojrzałości DevOps.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.