23 grudnia podszedłem do egzaminu Cisco DevNet Associate (DEVASC 200-901) i zdałem go uzyskując certyfikat. Długo się przed tym broniłem, ale powiedzmy, że presja otoczenia mnie zmusiła – kilku znajomych zdało ten egzamin też ostatnio. Poza tym skoro mam już “odznakę” DevNet Code Contributor, której oni nie mają, to mogę dołożyć do kolekcji DevNet Associate oraz DevNet Class of 2020. W dzisiejszym artykule podzielę się swoimi wrażeniami z samego egzaminu i przygotowań do niego.
Nie będę ukrywał, że nadchodząca premiera nowej ścieżki certyfikacyjnej Cisco DevNet była jedną z motywacji do stworzenia Szkoły DevNet. Jednak nie jedyną. Program zaproponowany przez Cisco jest ciekawy, ale nie można powiedzieć, że wyczerpujący. Nie chodzi o to, że skupiony jest na produktach oferowanych przez Cisco, co jest dość naturalne. Po prostu skonstruowany jest wokół jednego z obszarów automatyzacji. W większości rzeczywistych projektów będzie to działka zbyt wąska, a co za tym idzie może skutkować porażką całego projektu. Certyfikacja Cisco DevNet jest jednak bardzo dobrym punktem, aby po poznaniu fundamentów swobodnie rozwijać swoje kompetencje na innych obszarach automatyzacji.
Certyfikacja Cisco DevNet podzielona jest na dwa poziomy – Associate oraz Professional. Na poziomie podstawowym musisz zdać jeden ogólny egzamin. Przystępując do certyfikacji Professional konieczne jest zdanie dwóch egzaminów – ogólnego oraz jednego ze specjalistycznych. Podział taki wydaje się ciekawy i sensowny. Osoba zainteresowana wiedzą z zakresu automatyzacji w Data Center powinna się skupić na specyficznych zagadnieniach z tej działki, a nie na sucho zgłębiać tajniki Collaboration czy IoT.
Oprócz ogólnej wiedzy sieciowej związanej z zasadami działania sieci komputerowych czy projektowania infrastruktury możemy wyróżnić kilka obszarów technologicznych, których nie tylko podstawy należy zgłębić
Nawet jeżeli nie będziesz developerem piszącym kod, to jednak musisz oswoić się z myślą, że wchodzisz w świat projektów programistycznych. Przestajesz tworzyć konfigurację, a element aplikacji. Zatem twoje podejście do pracy musi być takie samo, albo co najmniej zbliżone do tego, jakie programiści wykorzystują w swojej pracy. Zacznij od zrozumienia czym jest CI/CD (Continuous Integration / Continuous Deployment) i jak to co stworzysz będzie wkomponowane w ten proces. Koniecznie zapoznaj się z takimi narzędziami jak Jenkins, Terraform, Puppet, czy wspomniany już Ansible.
Nie zapominaj jednak o fundamentalnej wiedzy z zakresu routingu, switchingu czy security. Nie pozwól zakurzyć się swojej wiedzy o różnych produktach. Zmieniając swoją rolę z “wyklikiwacza” konfiguracji w programistę nie zapomnij, że samo urządzenie czy aplikacja nadal działa tak samo. Twój router nie zmienił sposobu routowania pakietów ponieważ konfigurację wprowadziłeś za pomocą RESTCONF a nie CLI. Zainstalowany w sieci FirePower Thread Defence nadal w ten sam sposób będzie analizował zawartość pakietów niezależnie, czy konfigurację wprowadzisz za pomocą REST API czy “staroświeckiego’ GUI.
Projektując zautomatyzowany proces tak na prawdę piszesz algorytm. Sekwencję kroków do wykonania, na którą mogą wpływać różne zmienne. To też jest programowanie, choć może nie wiązać się z napisaniem nawet jednej linii kodu. Często może zostać sprowadzone do poukładania klocków i odpowiedniego zarządzania parametrami, które są do nich przekazywane i z nich odbierane. Jednak nadal jest to programowanie, w którym musisz myśleć o tym jakimi parametrami operujesz i jak poszczególne elementy algorytmu będą wpływały na siebie nawzajem.
Postaraj się o dostęp do środowiska testowego, nigdy nie eksperymentuj na środowisku produkcyjnym.