Rozwijanie na serwerze produkcyjnym

35

Dzisiaj zostałem wykrzyczany za opracowanie aplikacji na serwerze produkcyjnym. Cytat: „ rozwój na serwerze produkcyjnym jest niedopuszczalny - nigdy!

Oto sytuacja.

  1. Skonfigurowałem wystąpienie programistyczne: http://example.com:3000
  2. Instancja produkcyjna to: http://example.com
  3. Kończę wszystkie prace programistyczne http://example.com:3000i kiedy klient jest zadowolony ze zmian, przenoszę je do http://example.com.

Aplikacja, z którą pracuję, jest starą aplikacją Ruby on Rails i muszę powiedzieć, że początkowo próbowałem skonfigurować środowisko programistyczne lokalnie, ale nigdy nie udało mi się go uruchomić. Po krótkiej próbie poddałem się i postanowiłem rozwijać się na serwerze produkcyjnym.

Znowu jestem idiotą? Prawdopodobnie tak, ale zajmuję się tworzeniem stron internetowych od kilku lat i nigdy nie spotkałem się z taką sytuacją. Kto ma rację i dlaczego?

luk3thomas
źródło
46
Jedyną prawidłową retortą byłoby „posiadanie serwera produkcyjnego, którego nie można odtworzyć w fazie rozwoju, jest nie do przyjęcia - nigdy”.
Blrfl
49
Dla mnie prawdziwy problem polega na tym, że masz system produkcyjny, w którym nie masz pojęcia, co działa i jak jest skonfigurowany. Co byś zrobił, gdyby Twoja maszyna produkcyjna uległa awarii, tracąc wszystkie dane? Jeśli nie możesz teraz skonfigurować odpowiedniego środowiska programistycznego, co zrobisz, gdy będzie to jedyna opcja?
Greg Hewgill
@GregHewgill, tak, to dobra uwaga
luk3thomas
25
Greg ma rację, jeśli nie masz dość aplikacji do odtworzenia środowiska na maszynie programistycznej, to nie tylko nie powinieneś programować i testować na maszynie produkcyjnej, nie powinieneś mieć nawet dostępu do wdrażania na tym komputerze. Najwyraźniej się myliłeś, ale ja krzyczałbym na twojego szefa, że ​​dał ci dostęp, zanim w pełni zrozumiałeś, co robisz.
wałek klonowy
3
Jeśli nie możesz skonfigurować lokalnego środowiska programistycznego, nie powinieneś w ogóle się rozwijać.
Jas

Odpowiedzi:

58

Zwykłem programować na serwerze produkcyjnym. Może działać dobrze, ale jest niewskazany z co najmniej dwóch powodów:

  1. Kod programistyczny może powodować nieskończone pętle, wycieki pamięci lub inne problemy, które blokują procesor, pochłaniają całą pamięć lub w inny sposób wpływają na serwer w sposób, który wpłynie na kod produkcyjny.
  2. Jeśli musisz wprowadzić zmiany w komponentach środowiska serwerowego w ramach prac programistycznych, takich jak wersja Ruby lub MySQL lub cokolwiek innego, będziesz w stanie powiązać.
Jacob Terry
źródło
1
Tak, to dobra uwaga. Im więcej o tym myślę, macie całkowitą rację.
luk3thomas
6
Istnieje trzeci problem: bezpieczeństwo. Co się stanie, jeśli ktoś przeskanuje serwer produkcyjny i odkryje aplikację (programistyczną) - w rezultacie narażając ją na szwank? Ponownie, chociaż nie jest to prawdopodobny scenariusz, który jest prawie tym, co wszyscy mówią po naruszeniu serwera lub systemu.
Marco
Niesławny problem z nieskończoną pętlą ...
Mansuro,
3
@Marco W rzeczywistości jest to bardzo prawdopodobne, jeśli serwer jest publicznie dostępny. Serwery programistyczne zazwyczaj mają bardzo złe zabezpieczenia (ponieważ udogodnienia, takie jak debugery i ślady stosu, są zobowiązaniami, jeśli chodzi o bezpieczeństwo). Jeśli atakujący może eskalować uprawnienia poprzez wykorzystanie serwera deweloperskiego, może on / ona całkowicie posiadać aplikację produkcyjną.
Mark E. Haase
29

Jak powiedzieli inni, kodowanie w środowisku PROD naraża użytkowników na błędy. Nawet jeśli uruchomiłeś inną instancję, nadal masz udostępnione zasoby sprzętowe i nadal masz dostęp do plików produkcyjnych i baz danych. I jak niektóre komentarze podkreślić, jeśli instancja Dev zostanie posiekany (na przykład z powodu pominięcia go wytrzeć, a następnie ktoś odkrywa ogromny bezpieczeństwo wykorzystać w Rails), już teraz ma publicznie dostępną maszynę ze swojej aplikacji działającej jako brama do środka. Co byłoby ... niefortunne.

Różne firmy mają różne odpowiedzi na to pytanie, ale ogólnie można je podzielić w następujący sposób:

  • Czy wystąpił błąd?
  • Ile czasu zajęłoby przywrócenie zmiany (pracuję głównie w C ++, więc wycofanie pliku binarnego może potrwać znacznie dłużej niż w Rubim, szczególnie gdy „straciłeś” stary plik binarny i trzeba go ponownie skompilować)
  • Jaki jest efekt zmiany (przybliżony przewodnik: zepsucie przechowywanych danych jest o wiele gorsze niż brak przechowywania lub wyświetlania danych, co z kolei jest gorsze niż brak wyświetlania strony)
  • Gdybyś spieprzył, a potem wyszedł przez drzwi, czy ktoś wiedziałby, co zrobiłeś?
  • Czy istniała inna opcja wdrożenia, która zapobiegałaby / zminimalizowała / wykryła zakręcenie przed uderzeniem?

To daje ostateczne obliczenia:

  • Ile kosztowałoby to całkowicie niemożliwe do zepsucia przedsięwzięcie?

Teraz o tyle mniej warta jest cała struktura zarządzania dla faceta podejmującego decyzje budżetowe. Stąd shouty.

Jeśli pracujesz na wewnętrznej stronie firmy „O nas” i wpiszesz swoje własne imię na L. „God-like” Thomas, kłopotliwy problem z pseudonimem; jeśli pracujesz nad aplikacją zakupową o kluczowym znaczeniu dla biznesu, która przypadkowo wypisuje dane karty kredytowej ze strony głównej ... problem z pozwem sądowym. Pomiędzy tymi skrajnościami kryje się wszystko, od przeładowywania, paraliżującej produktywności i wszystkich innych rzeczy, które mogą odstraszyć klientów.

Powodem, dla którego nie pozwala się na to nawet na stronie „O nas”, jest to, że kodowanie bezpośrednio w produkcji jest uzależniające . Zaczynasz od robienia tego tylko dla nieletnich, ale z biegiem czasu jest o wiele szybsze, aby nie zmuszać DEV do działania.

Poza tym wielkość firmy może mieć duży wpływ. W dwuosobowym zespole, gdy coś zaczyna się psuć, pochylasz się przez ramię i mówisz „Oi, jackass, odłóż to”. W 300-osobowej firmie musisz zacząć się martwić, czy to niekompetencja, czy złośliwość, menedżerowie mogą ponosić odpowiedzialność za rzeczy, nad którymi nie mieli kontroli itp.

Na koniec dnia, jeśli wykonasz procedurę i spieprzysz, sprawdzą, co jest nie tak z tą procedurą. Jeśli ominiesz procedurę i spieprzysz, to teraz twoja odpowiedzialność spoczywa na sobie, nawet jeśli wina się trochę rozłoży. To, czy chcesz rzucić kostką, zależy od ciebie.

deworde
źródło
To dobre podsumowanie pułapek związanych z rozwojem w środowisku produkcyjnym , ale pytanie dotyczyło opracowania w osobnym środowisku na sprzęcie produkcyjnym .
Carson63000,
@ Carson63000 Zgodził się, a odpowiedź Jacoba jest zdecydowanie lepsza po tej stronie. Lekko zmieniłem mój.
deworde
13

Próbowałem skonfigurować środowisko programistyczne lokalnie, ale nigdy nie udało mi się go uruchomić. Po krótkiej próbie poddałem się i postanowiłem rozwijać się na serwerze produkcyjnym.

Wspieram instrukcje AVOID na serwerze produkcyjnym. Możesz być uzasadniony, aby to zrobić w GUN, jeśli jest to poprawka literówki w pliku konfiguracyjnym i nalegana przez twojego kierownika.

WHY NOT?- Ponieważ bardzo ryzykowne i zaimkowe stanie się później nawykiem , bardzo cię to złapie. Ponieważ krytyczne błędy / awarie produkcyjne mogą cię kosztować zwolnienie z pracy.

Pozwól, że powtórzę to jeszcze raz, nawet jeśli poprosiłeś o korektę literówki na productionserwerze, najpierw zrób to Staging. lub innymi słowy przetestuj swoje zmiany, przetestuj je i ponownie przetestuj przed wprowadzeniem do produkcji.

Dzieje się tak często w miejscach, w których kultura „rób to szybko i brudno ” wydaje się normą.

Edycja: Programowanie na serwerze produkcyjnym, jako osobne środowisko, również NIE jest akceptowane . Wszelkie problemy spowodowane w pracy mogą po prostu doprowadzić do awarii serwera produkcyjnego i wpłynąć na wydajność aplikacji produkcyjnej . Jako przykład pamiętam przypadek, gdy istniała luka w zabezpieczeniach, gdy mój poprzedni współpracownik próbował użyć serwera produkcyjnego WinServer 2003 do celów programistycznych.

EL Yusubov
źródło
To dobre podsumowanie pułapek związanych z rozwojem w środowisku produkcyjnym , ale pytanie dotyczyło opracowania w osobnym środowisku na sprzęcie produkcyjnym .
Carson63000,
Dzięki, dodałem edycję, która rozwiązuje problemy związane z robieniem tego.
EL Yusubov
10

To naprawdę problem z protokołem. Zasadniczo nie jest to coś, co chciałbyś robić. Chcesz zostawić maszyny produkcyjne w spokoju. Mogą zawierać poufne dane i nie chcesz narażać wydajności lub stabilności witryn produkcyjnych za pomocą kodu nieprodukcyjnego.

To powiedziawszy, są chwile, w których jest to powszechnie wykonywane. Jeśli jesteś w sytuacji, gdy wypompowujesz oprogramowanie o niskim natężeniu ruchu lub proste witryny CMS, prawdopodobnie nie będzie to stanowić problemu. Ale jeśli pracujesz nad czymś z wrażliwymi danymi lub procesami „krytycznymi dla biznesu”, naprawdę nie powinieneś ryzykować posiadania kodu programistycznego na tym samym komputerze.

bunglestink
źródło
Ok dzięki. Czy kod programistyczny może spowodować niestabilność maszyny? Pracuję nad starą aplikacją railsową. Wydaje mi się (naiwna osoba), że kod programistyczny http://example.com:3000nie miałby wpływu http://example.com.
luk3thomas
2
@ luk3thomas: cóż, jasne, nie powinno. Co się jednak stanie, jeśli wystąpi błąd w serwerze sieciowym lub frameworku Rails, który powoduje awarię serwera? Co jeśli, jak zasugerował Jacob Terry w swojej odpowiedzi, nieskończona pętla lub przeciek pamięci w twoim kodzie deweloperskim zasysa wszystkie zasoby na serwerze produkcyjnym i zagraża wydajności działającej witryny?
Carson63000,
1
Czasami jest to wymóg. Na przykład sklepy, które licencjonują drogie oprogramowanie i nie mają budżetu na drugą kopię tylko do pracy deweloperskiej.
Brian Knoblauch
8

Innym ważnym powodem, aby nie rozwijać się bezpośrednio w produkcji, jest to, że instancja programistyczna zwykle generuje i wyświetla pełne błędy i ślady stosu. Nigdy nie chcesz ujawniać tego użytkownikowi.

Tak, możesz je zalogować zamiast pokazywać je klientowi, ale to sprawia, że ​​debugowanie jest o wiele mniej zabawne niż jest już.

Dodano Rozwiązanie problemu ubocznego związanego z problemami z instancją programistyczną: Odniosłem wielki sukces we wdrożeniu maszyny wirtualnej opartej na VirtualBox , która powiela nasze środowisko produkcyjne (oczywiście nie tylko sprzętowe) z Ubuntu Server .

msanford
źródło
3
zauważył, dziękuję za radę w / VirtualBox
luk3thomas
1
@ luk3thomas Jest to również bezpłatne! Istnieje mnóstwo samouczków online dla VirtualBox + Ubuntu (prawdopodobnie jedna z najczęstszych kombinacji wirtualizacji).
msanford,
8

Dziwi mnie, że nikt nie wspomniał o najważniejszym z powodów, dlaczego absolutnie zabrania się tworzenia na serwerach produkcyjnych:

Nie zadzieraj z danymi produkcyjnymi, co może się zdarzyć tak łatwo!

Mały błąd w jednym miejscu prowadzi do gigantycznych problemów w innych obliczeniach, a następnego dnia wszystkie dane są śmieciami, a klient jest wkurzony. Jest to o wiele, znacznie gorzej niż błąd w interfejsie użytkownika lub mała awaria tu i tam.

W przypadku większości aplikacji wartość leży w danych, a nie w procedurach.

Sokół
źródło
1
Nauczysz się tego dość szybko po zepsuciu danych produkcyjnych. Chyba nie ma DB.
Rocklan
8

Zawsze staram się zapytać innych programistów, jakie są procedury dla konkretnej firmy. Ogólnie tak, zawsze powinieneś:

  1. Buduj lokalnie.
  2. Popchnij go do jakiegoś pudełka, które naśladuje produkcję tak bardzo, jak to możliwe, aby sprawdzić, czy gra tam ładnie.
  3. Ewentualnie przekaż go do instancji kontroli jakości lub certyfikacji, aby przekazać go klientowi / zespołowi kontroli jakości w celu przejrzenia zmian.
  4. Popchnij do produkcji.

Możesz użyć receptur Capistrano w połączeniu z GitHub, aby obsłużyć wszystkie te rzeczy za Ciebie. Jeśli musisz to robić ręcznie za każdym razem, może szybko się zestarzeć.

lscott3
źródło
szyny 2.3.11, prawdopodobnie skończę coś takiego
luk3thomas
1

Innym problemem związanym z tworzeniem na prod jest to, że czasami te rzeczy są pomijane w kontroli źródła i przyszłe wydanie może cofnąć twoją szybką poprawkę.

Jeśli jesteś w spółce publicznej w Stanach Zjednoczonych, nie powinieneś mieć nawet dostępu do produ z powodów prawnych. Zasadniczo w żadnej firmie programista nie powinien mieć dostępu do produktu (z powodów podanych we wszystkich odpowiedziach, a także z możliwych przyczyn prawnych), więc twój menedżer również nie ma racji, przyznając ci prawa do tego serwera.

HLGEM
źródło
0

Reguły, które używają „zawsze” lub „nigdy” są zwykle źle zdefiniowane. Będą wyjątkowe przypadki, w których złamanie najlepszej praktyki będzie uzasadnione. Znacznie lepsza rada brzmi: „Nie dotykaj serwerów produkcyjnych, chyba że masz bardzo dobre powody”

W mojej karierze znalazłem tylko dwa powody do zmiany kodu na serwerach produkcyjnych:

  1. Błędy lub zachowania, które występują tylko tam i nie są powtarzalne w środowisku programistycznym. Są to rzadkie, ale mogą być bardzo denerwujące i trudne do znalezienia.

  2. Bezpośrednie naprawianie błędu krytycznego, na który nie można czekać, aby przejść przez normalny proces wdrażania, jeśli zajmuje to więcej niż kilka minut. Następnie zostanie to wyjaśnione przez kierownictwo. Jeśli masz szczęście, powinieneś mieć tylko kilka z nich przez całą karierę.

Oba najlepiej pozostawić starszym programistom, którzy dokładnie znają systemy.

Daniel Iankov
źródło
Jeśli występują błędy występujące tylko w środowisku produkcyjnym, środowisko programistyczne nie jest wystarczająco blisko środowiska produkcyjnego. Powinieneś NAJBARDZIEJ CO NAJMNIEJ mieć środowisko przejściowe z dokładnie taką samą konfiguracją jak środowisko produkcyjne, aż do dokładnych ustawień systemu operacyjnego, sprzętu przetwarzającego i zainstalowanego oprogramowania.
Nzall