Zastanawiasz się czym jest środowisko testowe w IT lub czemu warto je wdrożyć? Akurat pojawiła się doskonała okazja i przykład, który warto omówić. Zatem do dzieła!

NAUCZ SIĘ MONITOROWANIA SIECI I SERWERÓW

Chciałbym również byś wiedział, że ten artykuł jest częścią cyklu “Oszukać przeznaczenie“. Materiały w nim zebrane mają na celu pomóc Ci przewidzieć oraz zabezpieczyć firmę przed komplikacjami i ogromnymi stratami finansowymi. Poprzednie znajdziesz w tym miejscu:

https://blog.askomputer.pl/category/bezpieczenstwo/

Środowisko Testowe? Na co to komu?

Ostatnio zrobiło się głośno o wpadce Mbanku, który testował powiadomienia push na środowisku produkcyjnym. Aby nie powielać treści na ten temat podam link z szerszym wyjaśnieniem:

https://www.benchmark.pl/aktualnosci/mbank-wyslal-do-klientow-dziwne-komunikaty-to-nie-jedyne-problemy.html

Obecnie dużo się mówi o tym, że Mbank podszedł do sprawy z dystansem i należy im zaliczyć na plus działanie marketingowców oraz poczucie humoru.

Osobiście uważam, że nie ma za co bić brawa. Cała ta akcja, mimo iż banalna i dosyć humorystyczna to jednak pokazała, że w mbanku leżą i kwiczą dobre praktyki IT. Czy to z powodu błędu stażysty czy braku procedur, nie ma tu wielkiego znaczenia.

Dzisiejsza bankowość to przede wszystkim technologia. A jeżeli popełniane są tak głupie błędy to dla mnie jest to zwrócenie uwagi na kwestię tego czy być może nie powinno się przenieść konta do innego banku. Do takiego gdzie jednak IT kontroluje w 100% swoją infrastrukturę i tym samym, dba o bezpieczeństwo naszych finansów.

Ale z dalszą krytyką już się powstrzymam. I tak już dostałem za to burę na naszej grupie Devopsiarzy.

Czy każda ZMIANA powinna być wprowadzana na środowisko testowe?

Bez względu na to jak duża zmiana jest wykonywana, koniecznie powinno się ją wykonywać na środowisku testowym. Nawet jeżeli testujesz jedynie powiadomienia PUSH w aplikacji mobilnej to najpierw powinieneś to robić na środowisku testowym.

A czym właściwie jest środowisko testowe i produkcyjne?

W uproszczeniu każdy serwer lub aplikacja powinna mieć „bliźniaka” w postaci środowiska testowego, które służy nam jako laboratorium. To na tym środowisku testujemy wszelkiego rodzaju zmiany i aktualizacje. Gdy okaże się, ze wszystko działa poprawnie to zmiana zostaje wprowadzana „na produkcji”.

Zróbmy przykład.

Wyobraź sobie system, który wykorzystuje 6 serwerów:

  • 1 Klaster HA składający się z 2 serwerów z bazą danych
  • 2 Klaster HA składający się z 2 serwerów z silnikiem WWW
  • 3 Klaster HA składający się z 2 serwerów aplikacją

Gdybyśmy teraz chcieli wykonać jakąkolwiek zmianę na którymś z tych serwerów to najpierw musielibyśmy ją przetestować na izolowanym środowisku. Takim do którego nie mają dostępu użytkownicy końcowi i brak działania nie spowoduje żadnych strat finansowych dla firmy.

Oczywiście, idealnie byłoby wykonać kopię takiego środowiska gdzie uruchomilibyśmy ponownie 3 klastry wykorzystujące 6 serwerów. Niestety, nie zawsze jest na to budżet. Dlatego można się pokusić o wykonanie lżejszej wersji bez klastrów.

Z 3 serwerami:

  • 1 serwer z bazą danych
  • 2 serwer z silnikiem WWW
  • 3 serwer z aplikacją

Wyglądałoby to następująco:

Gdybyś teraz chciał wykonać zmianę na klastrze z bazą danych to naturalnie wykonałbyś to na Klastrze numer 1. Aby ją przetestować to najpierw wprowadziłbyś zmianę na Serwerze numer 1 wykorzystując środowisko testowe.

Następnie, musiałbyś odczekać (uwaga – popularne słowo) kwarantannę na środowisku testowym i przetestować zmiany. Jeżeli wszystko będzie działać poprawnie to to samo wykonujesz na Produkcji. Oczywiście, nie oddaje to w 100% zmian na produkcji, bo tam dochodzą jeszcze wszelkie zależności związane z klastrem. Mimo wszystko, lepiej wykonać tak testy niż wcale.

Rozwiązanie za cebuliony

Oczywiście, jeżeli masz bardzo ograniczone środki to zawsze możesz uruchomić tylko jeden serwer. Będzie się na nim znajdować zarówno aplikacja, baza jak i silnik WWW. Pozwoli Ci to choćby na przetestowanie zmian kodu w aplikacji. Zawsze lepsze rozwiązanie takie niż żadne. Akurat wspomniani w dzisiejszym artykule bohaterowie wykonywali zmiany na warstwie aplikacji, więc nic nie tłumaczy ich wpadki.

W ostateczności mogli wykonać test na środowisku laboratoryjnym uruchomionym na jednej maszynie wirtualnej. Podejrzewam, ze jednak w tym przypadku komuś się pomyliły serwery 😉

Jak widzisz, nie jest to aż tak straszne jak się wydaje. Jeżeli masz jakieś pytania to zapraszam. Postaram się pomóc.

NAUCZ SIĘ MONITOROWANIA SIECI I SERWERÓW

Miłego dnia!

Arek