Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.

Transkrypt

1 Usprawnienie procesu zarządzania konfiguracją Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. 1

2 Typowy model w zarządzaniu IT akceptacja problem problem aktualny stan infrastruktury propozycja rozwiązania zmiana nowy stan infrastruktury potrzeba potrzeba - konfiguracja - usługi systemowe - funkcje systemu - parametry techniczne - itp,... weryfikacja - konfiguracja - usługi systemowe - funkcje systemu - parametry techniczne - itp,... 2

3 Typowy model w zarządzaniu IT akceptacja Potrzeba aktualny stan infrastruktury problem potrzeba propozycja rozwiązania zmiana nowy stan infrastruktury problem potrzeba Status Propozycja weryfikacja Wprowadzanie 3

4 Typowy model w zarządzaniu IT Propozycja Czym jest? Ogólnym opisem potrzeby. Bez szczegółów technicznych realizacji planowanych czynności. Zazwyczaj niekompletna często przy wdrożeniu okazuje się, że wymagane jest przeprowadzenie czynności dodatkowych. 4

5 Typowy model w zarządzaniu IT Propozycja Co tracimy? Informacje o wszystkich wykonanych czynnościach w systemie. Sposób realizacji operacji. Niezbędne informacje do wycofania wprowadzonych zmian. 5

6 Typowy model w zarządzaniu IT Status Potrzeba Wprowadzanie Efektywnie propozycja nie odzwierciedla faktycznych zmian dokonanych w infrastrukturze i nie stanowi odniesienia przy próbie przywrócenia lub duplikacji środowiska. 6

7 Typowy model w zarządzaniu IT Czy wprowadzona zmiana wciąż jest dostępna w systemie? Z jakiego powodu jest wycofana? Kto ją wprowadził w systemach? Kiedy została wprowadzona? czas 7

8 Typowy model w zarządzaniu IT Potrzeba Wprowadzanie Czy weryfikacja statusu faktycznie występuje w naszym modelu zarządzania infrastrukturą? Czy monitorujemy lub weryfikujemy stan wszystkich wprowadzonych modyfikacji? czas 8

9 Typowy model w zarządzaniu IT Spójność infrastruktury? Na których systemach zmiana została wprowadzona? Czy pojawiła się na wszystkich systemach? Czy została zaaplikowana tylko na tych systemach na których było to niezbędne? Co z systemami które w tym czasie były niedostępne? Co z nowymi systemami które dodamy do naszej infrastruktury? 9

10 Typowy model w zarządzaniu IT Potrzeba Wprowadzanie Brak pewności spójności naszej infrastruktury powoduje, że jakość wprowadzonej również jest niepewna. 10

11 Puppet Puppet jest narzędziem stworzonym do utrzymywania systemów w zdefiniowanym przez użytkownika stanie: wymuszona definicja sposobu wprowadzenia zmian widoczność zmian spójność systemów wsparcie dla wielu systemów operacyjnych architektura agentowa zarządzanie odbywa się z jednego centralnego miejsca cykliczność ciągłość działania 11

12 12 Puppet sposób działania

13 Puppet sposób działania Zbiór informacji o systemie, opisujący jego charakterystykę i stan. Zdefiniowany opis pożądanego stanu, w którym system powinien się znajdować. Raport zgodności systemu ze stanem pożądanym. 13

14 Zarządzanie konfiguracją Wymuszony opis sposobu realizacji i wykonywania powtarzalnych czynności. Weryfikacja stanu wprowadzonej. Automatyczna, zgodna z wcześniej opisanym sposobem, aplikacja w infrastrukturze. Automatyczne raportowanie o statusie wprowadzanej. Status Weryfikacja stanu Wprowadzanie Utrzymanie systemu w pożądanym stanie Potrzeba Tworzenie poprawki 14

15 7.3. W ramach projektowania systemu informatycznego bank powinien uwzględnić możliwość wprowadzania w przyszłości jego modyfikacji, wynikających w szczególności ze zmian w przepisach prawa, strategii działania banku lub obowiązujących w nim standardach. Oznacza to, że rozwijając systemy informatyczne bank powinien zidentyfikować możliwe do przewidzenia w uwarunkowaniach wewnętrznych i zewnętrznych i rozważyć zasadność zapewnienia elastyczności danego systemu w odpowiednim zakresie, umożliwiającej w przyszłości efektywne wprowadzanie niezbędnych zmian. 15

16 9.10. Bank powinien weryfikować predefiniowane ustawienia wprowadzano przez producenta urządzenia lub systemu pozostawienie konfiguracji domyślnej (a zatem powszechnie znanej, np. w zakresie standardowych kont i haseł) w znacznym stopniu zwiększa poziom ryzyka w zakresie bezpieczeństwa środowiska teleinformatycznego. 16

17 Git Rozproszony system kontroli wersji Dzięki rozproszonemu repozytorium nie ma jednego miejsca awarii Zyskujemy pewność spójności i braku kompromitacji naszego repozytorium: Obliczana jest suma kontrolna każdego pliku i commitu Zyskujemy pewność tego, że nasze pliki w repozytorium dokładnie takie same jak przy operacji commit i nic nie zostało zmienione w historii repozytorium 17

18 Zarządzanie konfiguracją Potrzeba Deweloper Deweloper Tworzenie poprawki Repozytorium centralne Integrator 18

19 Zarządzanie konfiguracją Środowisko produkcyjne v0.1 v0.2 v0.3 Zatwierdzenie zmian i Opis środowiska przeniesienie ich na systemy produkcyjne. Środowisko testowe Opis środowiska Środowisko rozwojowe Opis środowiska commit 19

20 Pion IT Departament aplikacji Departament utrzymania Puppet Git Departament bezpieczeństwa Produkcyjne Produkcyjne Produkcyjne Testowe Testowe Testowe Rozwojowe Rozwojowe Rozwojowe 20

21 Zarządzanie konfiguracją Potrzeba Akceptacja zmian Zyskujemy: historię modyfikacji autorów modyfikacji czas wprowadzenia modyfikacji przetestowaną i zaplanowaną metodę wdrożenia osobę odpowiedzialną za wprowadzenie do środowiska 21

22 9.12. Bank powinien posiadać sformalizowane zasady dokonywania zmian w konfiguracji komponentów infrastruktury teleinformatycznej, uwzględniające istotność poszczególnych komponentów i zapewniające: realizację zmian w sposób zaplanowany i kontrolowany, z uwzględnieniem wpływu danej na inne komponenty, zabezpieczenie komponentów przed wprowadzaniem nieuprawnionych zmian, możliwość wycofania zmian, w tym dostępność kopii awaryjnych konfiguracji komponentów, możliwość identyfikacji osób wprowadzających oraz zatwierdzających poszczególne w konfiguracji. 22

23 7.9. Funkcjonujące w banku środowiska rozwojowe, testowe i produkcyjne powinny być odpowiednio odseparowane. Wybrana metoda separacji (np. separacja logiczna z zastosowaniem wirtualizacji, separacja fizyczna itp.) powinna odpowiadać poziomowi ryzyka i uwarunkowaniom technicznym związanym z danym środowiskiem i funkcjonującymi w nim systemami. 23

24 9.11. Bank powinien przeanalizować zasadność (uwzględniając w szczególności poziom złożoności środowiska teleinformatycznego oraz stopień narażenia na ryzyko w zakresie bezpieczeństwa tego środowiska) i na tej podstawie podjąć odpowiednie decyzje dotyczące: opracowania standardów konfiguracyjnych, utrzymywania rejestru komponentów infrastruktury informatycznej wraz z podstawowymi informacjami na temat ich rodzaju i konfiguracji, utrzymywania elektronicznego repozytorium kopii zastosowanej konfiguracji. 24

25 Zarządzanie konfiguracją Weryfikacja stanu Potrzeba Informacja o niezbędnych modyfikacjach Akceptacja zmian Symulacja 25

26 Puppet i tryb bezoperacyjny System operacyjny Raport puppeta z utrzymywanego stanu Raport puppeta z planowanych zmian Środowisko produkcyjne v0.1 Opis środowiska v0.2 v0.3 Środowisko rozwojowe Opis środowiska 26 commit

27 Puppet i tryb bezoperacyjny info: Applying configuration version 'audyt wersja konfiguracji:0.2' notice: /Stage[main]//Node[default]/User[elmo]/ensure: current_value present, should be absent (noop) notice: /Stage[main]//Node[default]/Package[wget]/ensure: current_value present, should be absent (noop) notice: /Stage[main]//Node[default]/File[/tmp/plik]/ensure: current_value file, should be directory (noop) notice: Finished catalog run in 0.24 seconds 27

28 Zarządzanie konfiguracją Zyskujemy: Informację o koniecznych zmianach i ich zależnościach przed ich wprowadzeniem Testujemy poprawność nowej konfiguracji Możliwość wykorzystania rozwiązania jedynie do weryfikacji stanu infrastruktury Akceptacja zmian Potrzeba 28

29 7.8. Bank powinien zapewnić, aby procedury przenoszenia nowego systemu informatycznego lub już funkcjonującego systemu na środowisko produkcyjne minimalizowały ryzyko wystąpienia przestojów w działalności banku. W szczególności po przeniesieniu systemu na środowisko produkcyjne bank powinien zweryfikować poprawność jego działania i zgodność z wymaganiami, a następnie przez odpowiedni czas monitorować system pod tym kątem w celu identyfikacji ewentualnych problemów wymagających interwencji. W związku z tym, bank powinien przeanalizować zasadność (uwzględniając w szczególności możliwości techniczne oraz stosunek ryzyka do kosztów) i na tej podstawie podjąć odpowiednią decyzję dotyczącą zapewnienia mechanizmów umożliwiających powrót do stanu sprzed wdrożenia w przypadku wystąpienia sytuacji krytycznej (takich jak tworzenie kopii awaryjnych odpowiedniego obszaru środowiska teleinformatycznego). 29

30 Zarządzanie zdarzeniami Zbieranie informacji z całej naszej infrastruktury Analiza i korelacja zdarzeń Możliwość łączenia sposobu wprowadzenia z jej wpływem na infrastrukturę 30

31 Zarządzanie konfiguracją Przegląd zmian Potrzeba Akceptacja zmian Przegląd zmian 31

32 Zarządzanie konfiguracją Zyskujemy: Przegląd zmian z całej infrastruktury w jednym centralnym miejscu Automatyczne raporty o wykrytych nieprawidłowościach Historia zmian naszej całej infrastruktury Akceptacja zmian Potrzeba 32

33 7.7. Zarówno nowe oprogramowanie, jak i wprowadzane do już funkcjonujących rozwiązań informatycznych, powinny być testowane adekwatnie do swojej złożoności oraz wpływu na pozostałe elementy środowiska teleinformatycznego banku. Bank powinien posiadać metodologię testowania oprogramowania, uwzględniającą w szczególności następujące dobre praktyk: sposób organizacji testów powinien zapewniać możliwie wysoki stopień niezależności weryfikacji spełnienia przyjętych założeń, w testach powinni brać udział przedstawiciele możliwie szerokiego zakresu jednostek organizacyjnych banku wykorzystujących wdrażane rozwiązanie (lub w przypadku wprowadzania zmian jego modyfikowaną część), jak również obszarów technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego, scenariusze testowe oraz zakres i wolumen danych wykorzystywanych w testach powinny być możliwie zbliżone do procedur i danych przetwarzanych w ramach faktycznego korzystania z systemu, przy czym bank powinien zapewnić zachowanie odpowiedniego stopnia poufności rzeczywistych danych wykorzystywanych na potrzeby testów, sposób zgłaszania i dokonywania korekt błędów oprogramowania powinien być precyzyjnie określony i zapewniać rejestrację wszystkich zgłaszanych błędów, testy powinny być przeprowadzane w dedykowanym środowisku testowym 33

34 7.11. W banku powinien funkcjonować sformalizowany proces zarządzania zmianą w systemach informatycznych, określający zasady i tryb postępowania w zakresie: zgłaszania propozycji zmian, akceptacji zmian, określania priorytetów zmian, realizacji zmian, monitorowania realizacji zmian, testowania realizacji zmian, zamykania zrealizowanych zmian, zarządzania zmianami pilnymi / awaryjnymi. 34

35 Istotnych problemów nie da się rozwiązać na tym samym poziomie myślenia, na jakim je stworzyliśmy. -- Albert Einstein 35

36 Dziękujemy za uwagę Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. 36