Szanuj, że sysadmini mają zadanie do wykonania, i pozwól im wykonywać swoją pracę. Wiele firm ma niekompetentnych administratorów, co często nie jest realistyczne. Ale widziałem, jak aroganccy programiści ignorują rady grup systemowych, nawet po tym, jak sysadmini udowodnili swoje kompetencje.
Omów projekt nowego systemu z sysadmins. Często jest cenny wgląd. Programiści często patrzą na dyskusje z administratorami i stawiają wstępne wymagania jako „przedwczesną optymalizację”. Widziałem, jak szef grupy programistów powiedział, że marnowanie jego czasu to omawianie wymagań dotyczących nowych serwerów baz danych z sysadminami i DBA, nawet w zakresie opisywania, czy jest to obciążenie intensywnie zapisujące, czy wymagające odczytu, lub ile miejsca będzie potrzebne.
Omów problemy z wydajnością z sysadmins. Szczerze mówiąc, tylko sysadmini są w stanie poprawnie interpretować wskaźniki wydajności w systemach. Widziałem, jak programiści decydują, że Linux zawsze przecieka pamięć, ponieważ ilość wolnej pamięci zgłaszana przez „free” zawsze maleje, nawet po 10. wyjściu „free” jest wyjaśnione.
Nie wyciągaj wniosków bez przedyskutowania tego z administratorami. Widziałem, jak programiści utknęli w takich teoriach, jak: „bazy danych są zawsze związane z dyskami” (nie wiedzieli, że iostat nawet istniał), „RAID 5 jest szybszy w przypadku obciążeń transakcyjnych” (na podstawie przypomnienia o jednym systemie bazy danych, który został przeniesiony z jednej platformy sprzętowej na drugą - było to obciążenie wymagające intensywnego odczytu, rozwiązanie RAID5 miało coraz więcej szybszych dysków rozmieszczonych na większej liczbie kontrolerów. Ale zapomnieli o tych szczegółach i tylko pamiętali wnioski.)
Nie projektuj rozwiązania problemu systemowego bez omówienia go z sysadmins. Pracowałem w jednym patologicznym środowisku, w którym programiści zaprojektowali rozwiązanie i poprosili o niewielką pomoc przy implementacji. Członkowie grupy Unix oprócz mnie, szef grupy Unix i jego szef, chcieli traktować programistów jako „klientów”, a nie jako współpracowników próbujących stworzyć ogólną funkcję infrastruktury. Klient zawsze mający rację oznaczał, że nie ma wątpliwości, co robił i dlaczego. Byłem jedynym, który nalegałby na opisanie problemu, aby można było ustalić prawidłowe rozwiązanie. Nie działaj w sposób, który tworzy patologiczne środowiska, takie jak to. Nie przynosi to korzyści netto - zamiast tego zarządcy systemów będą działać defensywnie i wszyscy będą cierpieć.
Nie ma cię już w szkole. Są to systemy rzeczywiste i nie działają one w idealny sposób. Na przykład nie wszystko ma zerowe opóźnienie. Kiedy sysadmin ostrzega cię, że rozwiązania klastrowe służą wyłącznie celom politycznym, a dodatkowa złożoność systemu zmniejsza ogólną niezawodność, podejmij to poważnie. Musisz zaprojektować rzeczywiste tryby awarii, na przykład gdy stracisz serwer, z którym rozmawiasz przez TCP, połączenie prawdopodobnie nie zostanie zresetowane. Administratorzy systemów znają rzeczywiste tryby awarii.
Albo posłuchaj, co mówi ci sysadmin, albo poskarżyć się zarządowi, że twoi sysadmini są niekompetentni i muszą zostać zwolnieni. Ignorowanie swojego administratora systemu nie ma sensu.
Zastanów się, jak wdrożysz swoją aplikację. Uświadom sobie, że omawianie tego ze swoimi administratorami ma sens. Jeśli masz 100 identycznych serwerów, różniących się tylko jednym plikiem konfiguracyjnym, możesz rozważyć przechowywanie głównych kopii tych plików konfiguracyjnych w centralnej lokalizacji. Zrozum, o ile lepiej wszyscy są, jeśli twoja aplikacja jest łatwa do ponownego wdrożenia. Jeśli występuje problem z systemem, czy wolisz wdrożyć go ponownie w niecałą minutę, czy poczekać całe wieki, aż uszkodzony zostanie naprawiony? Jeśli możesz ponownie wdrożyć aplikację, system operacyjny można uaktualnić łatwiej i bezpieczniej. W przyszłości możesz się tym przejmować.
Jeśli masz problem, który Twoim zdaniem może wynikać z systemu operacyjnego, warto natychmiast zadzwonić do sysadmin, aby to sprawdzić. Ale po pobieżnym dochodzeniu nic nie ujawnia, masz obowiązek wyjaśnić problem.
Zrozum, że istnieje różnica między „reagowaniem powoli” a „brakiem odpowiedzi”.