W swojej karierze byłem zarówno programistą, jak i praktykiem ITIL na stanowisku operacyjnym. Dlatego DevOps był dla mnie naturalnym postępem.
Zawsze jednak zmagałem się z wysoce wyspecjalizowanym językiem, który wprowadza ITIL, i czyniąc go „przyjaznym dla programistów” na tyle, aby nie być całkowitą rezygnacją dla programistów.
ITIL to międzynarodowy system zarządzania usługami informatycznymi, który został opracowany przez 30 lat jako zestaw praktyk, które mają udowodnioną korzyść dla stabilności operacyjnej i dojrzałości organizacji.
Czy DevOps jest naprawdę kompatybilny z ITIL, czy w gruncie rzeczy musimy przyjąć ducha ITIL i „przetłumaczyć” go na język lepiej rozumiany przez zespoły programistów:
- Zarządzanie incydentami i problemami → Wady produkcyjne, błędy lub problemy
- Zarządzanie zmianami i wydaniami → Ciągła dostawa
- Zarządzanie zdarzeniami → Rejestrowanie, telemetria, oprzyrządowanie i alarmowanie
terminology
itil
operations
Richard Slater
źródło
źródło
Odpowiedzi:
Moim zdaniem kultura DevOps przychodzi wraz ze zmianą metodologii w kierunku zarządzania procesami Agile .
ITIL jest silnie ukierunkowany na wyraźny formalizm procesu i wyników, a zatem jest bardziej dostosowany do modelu Waterfall .
Nie oznacza to, że ITIL jest niezgodny z Devops, ale zwykle będzie to dwa osobne procesy o różnych ramach czasowych. Mam na myśli, że włączenie nowego produktu do referencji ITIL będzie zwykle opóźnione do momentu, gdy produkt / aplikacja zostanie na chwilę wydana w produkcji, gdzie wczesne pułapki i niektóre dokumenty potrzebne do integracji ITIL zostały zrobione i dostosowane po tym, jak produkt „ relacja na żywo".
Jedną z rzeczy w ITIL jest Projekt Usługi, który zakłada się, że zostanie zdefiniowany przed jakimkolwiek zadaniem programistycznym, zwinny proces będzie / może przeglądać projekt w każdej iteracji, łamiąc formalizm potrzebny w procesie ITIL.
Głównym celem ITIL jest, jak powiedziałeś, zapewnienie ram zapewniających, że nic nie zostanie pominięte między fazą projektowania / koncepcji a konserwacją (kompilacja / uruchomienie). W kulturze dewów cały zespół jest odpowiedzialny za wszystkie fazy w perspektywie długoterminowej, dlatego też formalizm został zredukowany.
Nie oznacza to, że musimy zapomnieć o ITIL, podstawowe zasady są absolutnie dobre i, moim zdaniem, powinny zostać wykorzystane jako lista kontrolna do zbudowania początkowego zaległości produktu. Po prostu przestrzeganie zasady ITIL z całym jej formalizmem jest sprzeczne z celem redukcji rynku, jakim jest szybkie iteracyjne tworzenie oprogramowania, a czasem nawet nie ma zastosowania, ponieważ między zespołami wymagana jest mniejsza transmisja informacji, ponieważ zadania wykonuje ten sam zespół. .
źródło
Mam certyfikat ITIL (choć minęło trochę czasu). Zgadzam się z Tensibai: ITIL i DevOps nie są niekompatybilne , ale to niekoniecznie czyni ich wspaniałymi przyjaciółmi.
Można argumentować, że procesy w ITIL muszą w jakiś sposób zachodzić, szczególnie w przypadku większych organizacji. Pomyślna integracja praktyk DevOps, w których ITIL jest już praktykowany, wymaga starannego planowania, komunikacji i wykonania. Z drugiej strony dotyczy to każdej transformacji DevOps.
Dla transformacji typu „greenfield”, gdzie nie ma ani ITIL, ani DevOps, stworzyłbym kombinację obu przy użyciu terminologii „mapowanej”, tak jak to opisano. Tak długo, jak wszyscy w organizacji są na tej samej stronie, używanie tego samego języka, ITIL i DevOps mogą wnieść wartość dodaną w połączeniu.
źródło
Lubiłem odpowiedź świadczonych przez IT Sceptic na odcinku od DevOpsCafe.org Jeśli dobrze pamiętam, jego sposób myślenia jest to, że jeśli faktycznie naprawdę zrozumieć ITIL, jest tam bardzo mały konflikt. Że większość wytycznych ITIL jest bardzo ogólna i że konflikty są w dużej mierze pomiędzy niektórymi implementacjami ITIL, a nie za faktyczną specyfikacją.
źródło