Jakie informacje o serwerze potrzebuje software house?

3 lutego 2022
Jakub Rojek Jakub Rojek
Zdjęcie autorstwa Christina Morillo z Pexels (https://www.pexels.com/pl-pl/zdjecie/inzynier-trzymajacy-laptopa-1181316/)
Kategorie: Analiza IT, Dla klientów, Wdrożenia

W każdym (lub prawie każdym) projekcie wykorzystującym komunikację internetową nadchodzi ten moment, w którym kolejnym krokiem jest wdrożenie aplikacji na serwer lub serwery. Zazwyczaj jest to etap obfitujący w emocje, ale niestety, nie tylko te pozytywne. Łatwo bowiem można wyobrazić sobie sytuację, w której oprogramowanie pieczołowicie przygotowywane na lokalnych maszynach programistów oraz testowane na serwerze przejściowym, ma problemy w produkcyjnej konfiguracji. Dlatego cała idea polega na tym, aby takim przypadkom przeciwdziałać i wręcz zapobiegać. W jaki sposób? Choćby poprzez wcześniejszy wywiad na temat serwera.

W niniejszym tekście przyjrzymy się punktom, które software house powinien odhaczyć już na wstępnym etapie prac (a zwłaszcza analizy) w kontekście docelowego środowiska dla systemu IT. Przy okazji, powiemy sobie, na co trzeba zwrócić uwagę podczas rozmów z klientem na ten temat. Tekst jest kierowany także właśnie do nabywców oprogramowania, którzy powinni być świadomi tego, jaka jest ich rola w przygotowaniu infrastruktury serwerowej dla firmy IT wdrażającej oprogramowanie.

O tym, kiedy w ogóle potrzebujemy serwera i jakie są rodzaje, możecie przeczytać w innym naszym artykule.

Kiedy zacząć rozmowę o serwerze?

Jak najwcześniej! Wielokrotnie pisaliśmy na blogu o tym, że warto już na początkowych etapach rozstrzygnąć wybór serwera (lub przynajmniej go zawęzić) ze względu na kwestie technologiczne. Planując architekturę oprogramowania, programiści muszą wiedzieć, na jakie rozwiązania mogą sobie pozwolić, gdyż będą mogły zostać obsłużone na środowisku docelowym, a które będą nieosiągalne. Nie ma nic gorszego niż przygotować system np. w Node.js, po czym dostać serwer, który obsługuje tylko PHP...

Jednak kwestia techniczna jest powiązana także z czynnikiem biznesowym - wiadomo, że w zależności od potrzebnych rozwiązań, integracji, infrastruktury itd. potrzebny będzie odpowiedni budżet. Z punktu widzenia klienta należy te kwestie wyjaśnić jak najwcześniej, jeszcze na etapie wyceny, gdyż musi być świadomy kosztów, które będą wymagane w celu realizacji opowieści użytkownika i innych ustaleń na etapie analizy. Oczywiście, nie da się wszystkiego na 100% przewidzieć od samego początku, ale można zaoszczędzić bardzo dużo czasu i nerwów podchodząc do tych tematów szczerze od samego początku. Nie ma nic gorszego dla zleceniodawcy niż w trakcie wdrożenia dowiedzieć się, że serwer, na którym będzie działać aplikacja, wyniesie znacznie więcej niż zakładał.

Serwer firmy IT czy klienta?

To kolejne istotne pytanie. Na wstępie powiedzmy sobie jedną rzecz - większość umów na stworzenie oprogramowania zakłada, że koszty serwera i ich późniejszego utrzymania NIE SĄ uwzględniane w wycenie, która jest objęta daną umową. Oczywiście, może tak być, że kosztorys zawiera już opłaty za infrastrukturę serwerową, jednak wówczas jest to podane wprost i w odpowiednim zakresie.

Zazwyczaj wdrażanie oprogramowania wygląda tak, że klient kupuje serwer na podstawie wskazówek software house'u i przekazuje dane dostępowe, aby zespół IT mógł dalej działać. Zdarzają się też sytuacje, w których software house ma do dyspozycji swoje serwery i oferuje na nich hosting. Zaletą jest oczywiście to, że wszystko jest w jednym miejscu i programistom też łatwiej jest wdrażać system w takim kontrolowanym środowisku. Wadą - nieliczne firmy IT mają to w ofercie, gdyż utrzymywanie oprogramowania a utrzymywanie infrastruktury serwerowej to dwie zupełnie różne rzeczy, wymagające różnych zespołów. O tym jeszcze dzisiaj sobie napiszemy.

Może jednak zaistnieć sytuacja, w której klient już dysponuje serwerem i zakłada, że to na niego zostanie wdrożona aplikacja. Oczywiście, jest to korzystne kosztowo dla zleceniodawcy, ponieważ skoro już ma wykupioną usługę, to czemu z niej nie korzystać. Jednak w tym przypadku powinnością software house'u jest dokładnie dowiedzieć się, co dany hosting oferuje.

Co software house musi wiedzieć o hostingu klienta?

W momencie, kiedy klient oferuje swój hosting (serwer) na potrzeby systemu, firma IT najczęściej musi się dowiedzieć następujących rzeczy (w nawiasach podane są przykłady odpowiedzi):

  • jaki system operacyjny jest na nim zainstalowany (teoretycznie powinniśmy spodziewać się Linuxa, jednak warto się upewnić),
  • jaki serwer HTTP jest na nim zainstalowany (np. Apache 2, NGINX),
  • jeśli jest potrzebny interpreter PHP, to w jakiej wersji jest dostępny (5.6, 7.1, 7.3, 7.4, 8.0 i inne),
  • czy jest możliwość zainstalowania innych serwerów, programów, interpreterów itd. (np. Node.js, Git),
  • w jakim trybie możliwy jest dostęp do serwera (tylko FTP/SFTP, konsola SSH),
  • jakimi zabezpieczeniami dysponuje serwer (hasło, tylko przez klucz SSH, tunel VPN itd.),
  • jakimi uprawnieniami będzie dysponował wdrażający (np. prawa roota),
  • jaki jest system do zarządzania bazą danych i w jakiej wersji (np. MySQL 5.7),
  • jaki jest tryb dostępu do bazy danych (konsola, phpMyAdmin itd.),
  • czy będzie możliwość uruchomienia usługi korzystającej z konkretnego portu (np. serwer websocketowy),
  • czy potrzebna będzie i została wykupiona domena przekierowana na ten serwer,
  • czy będzie możliwe utworzenie subdomen, np. sub1.domena.com, sub2.domena.com (np. do postawienia wersji testowych lub kilku backendów),
  • gdzie fizycznie znajduje się serwer - może mieć to znaczenie przy integracjach, szczególnie z wysyłaniem wrażliwych danych,
  • czy serwer oferuje również serwer pocztowy, z którego można skorzystać przy mailingu w aplikacji,
  • czy jest postawiony firewall i czy istnieją porty, które są zablokowane,
  • czy będzie możliwość zainstalowania certyfikatu SSL (dla stron HTTPS),
  • czy jest możliwość uruchomienia crona.

Oczywiście, to pewnie nie jest kompletna lista, jednak powyższe punkty to dobry drogowskaz nie tylko podczas rozmowy z klientem o jego obecnym hostingu, ale także podczas wyboru nowego i określenia możliwości, jakimi musi dysponować serwer dla aplikacji.

Jeden czy dwa serwery?

Nie bez powodu we wstępie zawarłem przykład (niestety, z życia wzięty) o tym, że systemy IT dobrze działają na komputerach programistów, ale niekoniecznie w środowisku docelowym. Jednocześnie wiele osób (w tym także klientów) zdaje sobie sprawę z tego, że aplikację trzeba najpierw przetestować na serwerze przejściowym, testowym czy developerskim (nazwy są bardzo różne). Dlatego warto nie tylko zadbać o wersję testową oprogramowania, ale także umieścić ją w systemie o zbliżonej (a wręcz identycznej) konfiguracji jak serwer docelowy. Dzięki temu większość niezgodności konfiguracyjnych zostanie wykryta na stosunkowo wczesnym etapie (gdyż wdrożenia testowe następują znacznie wcześniej niż końcowe), unikającym przy tym problemów na serwerze produkcyjnym. Niestety, nie zawsze jest to w pełni możliwe, ale warto trzymać się tej zasady.

Kto zajmie się obsługą serwera?

To bardzo istotny punkt, a tak często pomijany podczas rozmów. O ile jest raczej jasne, że wdrożenie i aktualizowanie wersji oprogramowania na serwerze należy do powinności software house'u (chyba że zostanie określone inaczej), o tyle utrzymywanie i reagowanie na zdarzenia nie są już sprawą oczywistą dla obu stron.

Programiści zajmują się oprogramowaniem - jego projektowaniem, tworzeniem i później faktycznie utrzymywaniem. Ale pod kątem jego kodu i funkcji. Zazwyczaj software house'y nie monitorują działających aplikacji i tym bardziej serwera - to zadanie administratorów, którzy się na tym znają i potrafią rozwiązywać problemy konfiguracyjne na środowisku docelowym, a w ostateczności (gdy istnieje obawa, że problem na serwerze wynika z błędu w aplikacji) poinformują o tym zespół programistów. Oczywiście, w większych "domach oprogramowania" istnieje opcja wykupienia takiej dodatkowej usługi, jednak zwykle jest to możliwe dlatego, że większa firma może zostać rozbudowana także właśnie o dział administratorów i devopsów.

Dla klienta może to nie być jasne, dlatego warto o tym porozmawiać również na początku współpracy, aby żadne karty nie były zakryte, gdyż zaowocowałoby to później przykrą niespodzianką po obu stronach. Czasami jest tak, że ktoś bardziej techniczny po stronie klienta, który i tak czuwa nad infrastrukturą IT w jego firmie, może pełnić rolę "strażnika", który po odpowiednim przeszkoleniu przez zespół IT będzie potrafił zareagować w większości sytuacji i utrzymać bezpieczny stan aż do konsultacji z software housem. Należy zwrócić też uwagę, że administracja serwerem wymaga trochę innego rodzaju umiejętności i wiedzy niż programowanie - to sztuka rozwiązywania niezgodności konfiguracyjnych w systemie operacyjnym, dbanie o sieć, wiedza o odpowiednich parametrach poprawiających osiągi serwera, a także nadawanie i utrzymywanie odpowiednich uprawnień.

Przy tej okazji warto też podkreślić, że wdrożenie kodu przez software house nie jest jednokrotną operacją - oprogramowanie należy utrzymywać i na pewno programiści będą jeszcze musieli reagować w przypadku wykrycia błędów bądź zwyczajnie zmian zgłoszonych przez klienta, które mogą pomóc mu w lepszym korzystaniu z pracy specjalistów IT. Należy zatem opracować procedurę nie tylko wdrożenia systemu od początku, ale też jego późniejszej aktualizacji, najlepiej w taki sposób, aby przerwa techniczna była jak najkrótsza. W przypadku bardziej złożonej architektury składającej się z wielu komponentów, nie jest złym pomysłem przygotowanie instrukcji, aby procedura wdrażania była jak najszybsza i powodowała mniej nerwów, szczególnie jeśli zespół później się rozrośnie.

Podsumowanie

W powyższym tekście starałem się przedstawić główne aspekty planowania miejsca, na którym będzie później działać wymarzone oprogramowanie. Nawet, jeśli to środowisko jest najprostsze z możliwych (czyli jeden serwer lub konto hostingowe), to i tak pozostaje wiele punktów do przedyskutowania, a które mogą mieć niebagatelne znaczenie dla późniejszych decyzji technicznych czy biznesowych.

Pozdrawiam i dziękuję - Jakub Rojek.

Lubimy pisać, nawet bardzo, ale na co dzień tworzymy aplikacje webowe i mobilne. Sprawdź niektóre z wykonanych przez programów.

O autorze

Jakub Rojek

Główny programista i współwłaściciel Wilda Software, z wieloletnim doświadczeniem w tworzeniu i rozwoju oprogramowania, ale także w pisaniu tekstów na różnorakich blogach. Zaprawiony w boju analityk i architekt systemów IT. Jednocześnie absolwent Politechniki Poznańskiej i okazjonalny prowadzący zajęcia na tej uczelni. W wolnych chwilach oddaje się graniu w gry wideo (głównie w karcianki), czytaniu książek, oglądaniu futbolu amerykańskiego i e-sportu, odkrywaniu cięższej muzyki oraz wytykaniu innym błędów językowych.

Jakub Rojek