SysAdmin i programista: Obowiązki [zamknięte]

Jeśli chodzi o coś takiego jak produkcyjny serwer WWW, jaka jest najlepsza praktyka w zakresie odpowiedzialności sysadmin i programisty? W szczególności myślę o aktualizacji / instalacji oprogramowania. (W moim rozumieniu deweloper nie powinien mieć dostępu do roota na serwerze produkcyjnym).

Tak więc produkcyjny serwer WWW obsługuje Wordpress i należy go zaktualizować do najnowszej wersji. Kto jest odpowiedzialny za aktualizację?

Co jeśli deweloperzy mają niestandardowe wtyczki do hakowania lub niestandardowe pliki podstawowe w aplikacji (w tym przykładzie WP)?

Przekonałem się, że w większości przypadków, jeśli TY jesteś odpowiedzialny za fizyczny serwer, najlepiej NIE udzielać dostępu do roota deweloperom.

To trochę debata o „świętej wojnie”, ponieważ jestem pewien, że znajdziesz programistów, którzy się z tym nie zgadzają. Osobiście byłem po obu stronach tej debaty.

Moje GŁÓWNE uzasadnienie, by nie udzielać deweloperom (nawet w 100% zaufanym programistom) dostępu do roota, to dlatego, że najczęściej potrzebny jest pakiet, aby XYZ działał poprawnie. Oni idą naprzód i instalują go ... lub zmieniają konfigurację czegoś, co już jest na miejscu, aby działało ... lub ... cóż ... masz pomysł.

Mijają miesiące… serwer wymaga ponownej instalacji lub odtworzenia… i nagle nikt nie wie, dlaczego „Działa na starym serwerze, ale nie na nowym”.

Odpowiedzią jest oczywiście to, że dokumentacja, którą przeglądasz, nie zawiera wszystkich małych pakietów i poprawek, które programiści zrobili, aby system działał za pierwszym razem.

Dla obu stron może to być uciążliwe ... ale jeśli sysadmin jest odpowiedzialny za serwer, pakiety i dokumentację ... a programista jest odpowiedzialny za rozwój i oprogramowanie ... Myślę, że Przekonam się, że w końcu było warto.

Jeśli deweloper potrzebuje niestandardowej wtyczki, modułu, konfiguracji, ulepszenia ... nie ma problemu ... zrób to dla nich ... ale DOKUMENTUJ IT, abyś mógł go odtworzyć następnym razem.

Złota reguła : Nie pozwól, aby osoby niebędące administratorami dotykały niczego, co nie chcesz złamane i za które będziesz odpowiedzialny.

Twórcy powinni mieć dostęp do środowiska testowego. Gdy ich praca jest gotowa do umieszczenia na maszynie produkcyjnej, należy ją przekazać administratorowi sys. Jeśli twórcy wykonali swoją pracę i odpowiednio udokumentowali procedurę, wszystko pójdzie dobrze. Jeśli nie, muszą zostać wykopane z tyłu za nieodpowiednie testowanie.

Byłem również w tej bitwie. Moja odpowiedź brzmi: ten, kto jest odpowiedzialny za czas pracy serwera, powinien być odpowiedzialny za wszystkie aktualizacje, zmiany itp. Itd. Nobodoy powinien mieć możliwość wykonywania tego typu funkcji na serwerze. Jeśli Twoim zadaniem jest upewnić się, że serwer jest uruchomiony i jeśli szef pociąga cię do odpowiedzialności za serwer, to Twoim obowiązkiem jest jego utrzymanie i zabezpieczenie.

Większość programistów powie ci, że potrzebuje dostępu na poziomie administratora do serwera, a większość z nich nie zgadza się ze mną, ale to ja muszę go ponownie uruchomić o 2 nad ranem, gdy się rozłączy, musi go odbudować po nieudana aktualizacja, przestoje obciążają mój dział itp. itd. Muszę odpowiedzieć CIO za wszystko, co ma wpływ na naszą umowę SLA, dlatego jestem jedynym, który uzyskuje dostęp na poziomie administratora do serwera i „ m odpowiedzialny za wszystkie komponenty, aktualizacje, zmiany itp.

100% się zgadzam. Deweloperzy przez większość czasu nie są świadomi, jak działają rzeczy syadmin. Jeśli czegoś potrzebują, pytają cię, to wszystko. Myślisz o tym, jak i kiedy i dostarczasz im użyteczny pakiet. (tak jak oni muszą wysyłać e-maile, TY jesteś tym, który skonfiguruje Postfix). Co więcej, będą mieli tendencję do myślenia, że ​​w większości przypadków dostęp do roota sprawi, że rzeczy będą działać, jeśli nie będą w stanie tego zrobić przy normalnym dostępie. Zgadzam się z innymi tutaj, nie będą z tobą o 2 nad ranem, kiedy zobaczysz problem. Miałem tę sprawę kilka tygodni temu, programista chciał zaktualizować swoje wordpress. Powiedziałem mu do dziennika zmian RTF, ponieważ dla niego było to bezużyteczne, proces aktualizacji odbywa się za pomocą pięknego interfejsu. Cóż, aktualizacja nie działała, zapisałem jego aplikację, wykonałem skrypt kopii zapasowej nie on. Beze mnie nie byłby w stanie przywrócić strony.

Istnieje tendencja do zatarcia rozróżnienia między programowaniem a operacjami. Uczyń programistów sysadminami i programistami sysadmins.

W tym sensie wordpress mógłby skorzystać z pewnej pracy nad zautomatyzowanym (i programowym) tworzeniem blogów. Wielu użytkowników wordpress utrzymuje więcej niż kilka instancji WP / WPMU, a ich aktualizacja na czas jest co najmniej uciążliwa.

Miły (i zabawny) przegląd filozofii można znaleźć na slajdach Agile Infrastructure z Agile 2009

Programiści nie powinni mieć korzeni na produkcji; wszyscy oprócz deweloperów zgadzają się na to. Ale programiści mogą coś zjeść i zjeść. Jestem nieco zaskoczony, że nikt nie wspomniał o tym wyraźnie:

Jeden z moich bardzo długich klientów małych firm ma stronę internetową z instalacją Drupala, kilka stron WordPress, forum SMF i kilka innych przypadkowych małych aplikacji internetowych. Jestem administratorem kontraktu (z powodów historycznych aktualizuję / hakuję WordPress i SMF w razie potrzeby), a mój klient ma swoich własnych deweloperów kontraktowych Drupal. Środowisko to kilka maszyn wirtualnych VMware na publicznym dostawcy chmury.

Programiści naprawdę chcą mieć dostęp do roota i trochę go potrzebują. Ich obowiązkiem jest napisanie reguł przepisywania nginx, aby na przykład wszystkie niestandardowe rzeczy Drupala działały. Ale w piekle nie dam im dostępu do roota na serwerze produkcyjnym, a mój klient się ze mną zgadza.

Więc skompromitowaliśmy się: mają dostęp do roota na testowym serwerze internetowym (który jest zasadniczo identyczny z produkcyjnym, z wyjątkiem jego adresu IP i znajduje się w tej samej chmurze). Które, podobnie jak produkcja, ma etckeeper, dzięki czemu mogę zobaczyć wszelkie zmiany, które trzeba wprowadzić, i wszelkie zainstalowane pakiety. Mogę następnie wprowadzić zmiany do produkcji lub powiedzieć im, co jest nie tak z tym, co chcą zrobić. A jeśli naprawdę spieprzyli (jeszcze tego nie zrobili, dzięki gawd), mogę łatwo przywrócić ich zmiany.

W ogóle nie mają dostępu do serwera produkcyjnej bazy danych; nie mają nawet loginów użytkowników. Tylko mój klient i ja.

(Sama aplikacja internetowa wdrażają bezpośrednio za pomocą git, a jeśli ją zepsują, mogą to naprawić i wyjaśnić mojemu klientowi, dlaczego nadal powinni być jego programistami. Chociaż mój klient wysłałby mi taką wiadomość e-mail, aby mógł śmiej się z nich lub z twarzy).

Root == Administrator systemu.

Użytkownicy == Programiści, DBA lub Użytkownicy.

Root nie zna snu, gdy serwer jest wyłączony, root chroni użytkowników przed sobą, root chroni dane użytkowników przed siecią, root stawia zdrowie serwera ponad wszystkich użytkowników. Osioł roota jest na linii, gdy serwer jest w trybie offline. Serwer szczęśliwy, root szczęśliwy!

Najczęstsze powody nieplanowanego przestoju: Użytkownicy, nieudokumentowane zmiany w środowisku i backhoes. Serwery robią dokładnie to, co im powiedziano, że nie tylko przypadkowo się psują. Hakerów, o które pytasz, nie jest to, czy, kiedy ... dlatego potrzeba "roota".

00:33 CDT czy wiesz, gdzie są twoje kopie zapasowe i dokumenty odzyskiwania po awarii? :-p

Administratorzy systemów powinni mieć dostęp administratora (tak jak mówi tytuł). Nikt inny nie potrzebuje dostępu do serwerów produkcyjnych. Jeśli programiści muszą rozwiązać problem w systemie produkcyjnym, problem ten powinien być powtarzalny w środowisku programistycznym. Jeśli nie, mogą usiąść z sysadminem i przejrzeć system.

Deweloperzy nie lubią nie być w stanie dotknąć produkcji, ale to nie jest praca. Zadanie polega na napisaniu oprogramowania i przekazaniu go administratorom systemu w celu wydania wersji produkcyjnej. Jeśli wszystko udokumentowali (i pamiętają, że w większości sklepów dokumentacja to nieprzyzwoite słowo), wydania powinny pójść dobrze.

W spółkach publicznych w USA masz do czynienia z SOX, HIPPA itp. Większość tych zapomnianych przez Boga przepisów faktycznie pomaga w tym sporze. SOX nakazuje rozdzielenie obowiązków, co wymaga od programistów trzymania się z dala od systemów produkcyjnych.