Co chcielibyście, żeby programiści zrobili inaczej? [Zamknięte]

Jako programista spędzam większość czasu na myśleniu o kodzie, interfejsie użytkownika, strukturach danych itd., Ale (dzielnie przyznam), nie zastanawiam się nad implikacjami mojej aplikacji dla sysadminów i DBA, dopóki nie nadejdzie czas na wdrożenie Aplikacja.

Po pierwsze przepraszam. Po drugie, czego chciałbyś ja i inni programiści, z którymi miałbyś do czynienia, zrobiłbym inaczej? Jakie rzeczy ułatwiłyby ci życie, spowodowały mniej problemów, zachęcały do ​​współpracy i ograniczały awarie, problemy z wydajnością i koszmary konfiguracyjne?

1. Pomyśl i wbuduj zabezpieczenia od 0.
2. Używaj kontroli wersji do wszystkiego: kodu źródłowego, dokumentacji, konfiguracji itp.
3. Dokumentacja, dokumentacja, dokumentacja.
4. Czysta instalacja i deinstalacja przy użyciu natywnego opakowania
5. Oddziel dane konfiguracyjne od bibliotek i plików wykonywalnych
6. Obsługa równoległego uruchamiania różnych wersji na potrzeby testowania i migracji
7. Solidne, konfigurowalne rejestrowanie
8. Lekki, dokładny i bezpieczny monitoring
9. Sprawdzanie aplikacji i tworzenie kopii zapasowych
10. Jak Twoja aplikacja reaguje na problemy: brak pamięci, pełny system plików, brak sieci, brakujące / uszkodzone pliki konfiguracyjne, przesunięcie czasowe?
11. Zawsze należy mieć osobne środowiska programistyczne, testujące i produkcyjne. Z całym darmowym oprogramowaniem VM nie ma wymówki!

Pamiętaj, że Twoja aplikacja prawdopodobnie ma więcej stanów niż w górę lub w dół. Narysuj diagram stanu. Większość aplikacji ma następujące stany:

• na dół
• inicjowanie
• poprawa
• praca up-but-not-accepting
• Czekanie
• punkt kontrolny
• przetwarzanie
• kończąc
• wyłączanie
• na dół

Zastanów się, co się stanie, jeśli system ulegnie awarii podczas każdego stanu. W jaki sposób sysadmin będzie monitorował i kontrolował zmiany stanu?

Odróżnij „użytkownika” od SA.

„Użytkownik” musi wiedzieć, jak korzystać z oprogramowania. Użytkownicy nie dbają o takie rzeczy, jak instalacja oprogramowania.

SA nie dba o to, jak korzystać z oprogramowania, ale musi znać kilka istotnych szczegółów na temat instalacji oprogramowania.

Napisz dokument osobno dla każdej z tych ról, w tym informacje istotne dla każdej z nich.

Jednym z moich życzeń jest włączenie odpowiednich komunikatów do wyjątków i kodów błędów. Jest to całkowicie nieprzejrzyste dla kogoś, kto nie opracował aplikacji, co to JimmyNotAtHomeException: it's late!znaczy.

Ale taka wiadomość Unable to find jimmy - initial manual call_mother procedurejest bardzo pomocna.

Komunikacja, komunikacja, komunikacja. Każdy problem między sysadminem a deweloperem prawie zawsze można prześledzić z powodu braku komunikacji. Jeśli przed projektem sysadmins (lub jego przedstawiciel) i deweloperzy spotkali się i przeprowadzili miłą dyskusję na temat ram, SOOOOOOOOOO można uniknąć wielu problemów. Nie mogę powiedzieć, ile rzeczy się sfaulowało, ponieważ rozwijasz wszystkich na jednym pudełku w fazie rozwoju, tylko po to, aby patrzeć, jak spada w płomieniach w prod, ponieważ aplikacja zostaje następnie rozdzielona na serwer aplikacji + serwer DB + serwer interfejsu itp. Wyrazy uznania za poruszenie tego tematu.

Zaangażuj nas na początku projektu. Jak prawdziwy naprawdę wcześnie, na funkcjonalnym etapie specyfikacji.

Ktoś inny wspomniał o konieczności ręcznej instalacji na każdym komputerze, ale to samo dotyczy konfiguracji i zmian konfiguracji. Jeśli zdecydujesz się przechowywać coś takiego jak ciągi znaków po stronie klienta i będziesz musiał je regularnie aktualizować, prawdopodobnie będziemy chcieli cię zabić .

Wybierz technologię, którą można właściwie centralnie zarządzać i konfigurować z tego samego powodu. Upewnij się, że dobrze integruje się z wszelkimi używanymi przez nas narzędziami centralnego zarządzania.

Zawsze testuj, używając najniższego wspólnego mianownika. To znaczy, że nie jest administratorem, w najbardziej prymitywnym systemie operacyjnym, najczęściej używanym pakiecie aplikacji i formie przeglądarki. Nie podoba nam się, aby wymagana aktualizacja przeglądarki dla wszystkich naszych użytkowników wylądowała na nas w ostatniej możliwej chwili.

Nie wahaj się nas obwiniać, gdy coś pójdzie nie tak. W mojej starej pracy za każdym razem, gdy aplikacja pękała, programiści natychmiast wskazywali na nas palcem. „Zainstalowałeś nową łatkę, nie uaktualnisz przeglądarek, twoje zabezpieczenia są zbyt ścisłe” czy cokolwiek innego. To generuje destrukcyjną atmosferę. Naprawdę jesteśmy po tej samej stronie i chcemy z tobą współpracować, aby to naprawić, ale nie możemy w takich okolicznościach.

Nie bądź elitarny.

„Nie marnuj mojego czasu, kolego Jesteś tylko administrator dogsbody;. I napisanie oprogramowania i ty tylko naprawiać go tak po prostu zamknąć się ze swoimi drobnymi obaw i zrobić tak jak mówię, OK.?”

Deweloper powiedział mi kiedyś te słowa (1). W e-mailu. CC do dużej grupy dystrybucyjnej. Implikacja była jasna: jako programista był panem i panem całego wszechświata oprogramowania; i byłem po prostu robotnikiem zatrudnionym do wykonywania zadań zbyt trywialnych, aby mógł tracić cenny czas. Oczywiście jest to prawie najgorszy przykład, ale wiesz, słyszałem mocne i słabe echa tego komentarza od wielu programistów zarówno przed jak i po (2).

Możesz zarobić więcej pieniędzy niż ja (ale nie zakładaj tego!). Ale zespół musi zbudować, obsługiwać i utrzymywać systemy, na których polegają nasi użytkownicy. Ostatecznie wszyscy im służymy.

Rozumiem, że twoja praca i twoje umiejętności są inne niż moje. Szanuję twoje umiejętności. Mam nadzieję, że odpowiesz na moje pytania, nawet jeśli wydają ci się elementarne i głupie. Z przyjemnością oddam tę uprzejmość!

Nie jestem na szalonej wyprawie, ponieważ tak wielu złych (lub po prostu nieświadomych) deweloperów powiedziało, myślało i publikowało na różnych forach. Ale moje obawy są inne niż twoje, a moje pytania i sugestie nie służą mojemu ego. Rzeczywiście moim zadaniem jest sprawienie, abyś wyglądał lepiej, utrzymując Twoje aplikacje w doskonałym stanie, dostępne i reagujące na wszystkich użytkowników. Aby to zrobić, muszę utrzymać resztę sieci i systemów w doskonałym stanie.

Jestem w pełni świadomy, że w przeszłości spotkałeś się z głupimi, szalonymi z władzy i / lub po prostu leniwymi administratorami. Staram się nie być jednym i nie wyglądać jak jeden. Jeśli zostawisz miejsce dla tej możliwości i potwierdzisz to, kiedy ją zobaczysz, jestem prawie pewien, że dostaniesz to, czego potrzebujesz, podczas gdy te inne dupki wciąż się wściekają na temat tego, co to za dupek, ich sysadmin.

(1) Nalegał również, aby jego program (narzędzie do pisania i zarządzania wymaganiami oprogramowania) potrzebował uprawnień administratora domeny do zainstalowania i uruchomienia. To było poważne zagrożenie bezpieczeństwa.

(2) Współpracowałem również z wieloma wspaniałymi programistami, którzy mogliby uczyć w razie potrzeby i uczyć się w razie potrzeby.

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”.

Skonfiguruj i ułóż wszystko w przewidywalny sposób z przewidywalnymi sposobami ich zmiany dla systemu operacyjnego (en), dla którego tworzysz. To znaczy wszystko. Na przykład: OpenLDAP ma dziwny sposób robienia loglevels; niektóre serwery IMAP nawet nie mają plików konfiguracyjnych, ale muszą mieć wkompilowane opcje; niektóre pakiety chcą, aby ich zawartość znajdowała się w jednej określonej ścieżce katalogu, co nieuchronnie złamie konwencje określonego systemu operacyjnego. Te rzeczy wyróżniają się jako brodawki na moich zwykłych konfiguracjach.

Jest to ogólna zasada, ale nie zakładaj, że jesteś wyjątkowy, i dlatego pobłogosławiłeś złamanie ogólnych konwencji dotyczących tego, jak pakiety oprogramowania ogólnie działają na twojej platformie, chyba że istnieje uzasadniony powód związany z twoim oprogramowaniem, który tego wymaga. „Zdecydowanie uważam, że tak powinno być”, nie jest wystarczająco dobre, aby przerwać zwykłą konfigurację każdego; musi to być powód związany z funkcją, którą twoje oprogramowanie próbuje wykonać.

Jeśli z aplikacją związana jest komunikacja między serwerami, w fazie projektowania należy uwzględnić co najmniej jednego administratora systemu. Ponadto wyraźnie udokumentuj zależności od innych usług: SQL, SMTP, HTTP itp. ... Nie każ nam zgadywać, co robisz, ani nie możemy ci pomóc, gdy coś nie działa tak, jak się spodziewałeś.

Umożliwiaj wdrażanie oprogramowania na dziesiątkach lub setkach systemów w sposób zautomatyzowany. Jeśli organizacja potrzebuje pakietu oprogramowania, sysadmins prawie na pewno nie ma czasu, aby zainstalować go ręcznie na każdym urządzeniu. Jeśli plik musi zawierać informacje o licencji, udokumentowanie sposobu jego dostarczenia byłoby ogromną korzyścią.

Adobe historycznie miał kilka instalatorów, z którymi praca była naprawdę trudna ; proszę celować wyżej!

Pomyśl o skalowaniu od pierwszego dnia. Sysadmini mogą robić cuda, rzucając pieniądze / sprzęt na problem z wydajnością, ale czasami żadna z nich nie pomoże - w szczególności myśleć o blokowaniu - czasami nie możesz wykupić się z problemu z blokowaniem. Dziękuję za pytanie :)

Aha i staraj się być 64-bitowy tam, gdzie to możliwe, i wielowątkowy :)

Projekt do operacji.

Ponad wszystko inne tutaj ...

• Zapytaj o symulowane środowisko produkcyjne (serwer programistyczny lub maszynę wirtualną z taką samą konfiguracją jak serwer na żywo), a następnie użyj go do przetestowania procesu wydania. Następnie przekaż nam ten proces wydania, w tym listę zmian i kolejność ich zastosowania (tj. 1. Wejdź w tryb konserwacji, 2. zastosuj aktualizację SQL, 3. zaktualizuj źródło do wersji X, 4. wyjdź z trybu konserwacji, 5. módl się)
• Upewnij się, że masz tryb konserwacji, który może wyrzucić użytkowników w celu zachowania integralności danych. Nie chcesz, abyśmy przeprowadzali dużą aktualizację systemu na kilku serwerach z zalogowanymi użytkownikami i realizującymi transakcje ... w większości przypadków jest to przepis na niepowodzenie.
• Użyj nieco rozwiniętego modelu programistycznego. Na przykład wszystkie nasze nowe aplikacje w pracy (grupa internetowa) używają Zend Framework.
• Podaj nam dzienniki zmian, które możemy odczytać, w tym listę naprawionych błędów, które możemy sprawdzić, aby zorientować się w zakresie zmian. Czasami możemy zidentyfikować potencjalne problemy tylko dlatego, że mamy inny punkt widzenia.

Chociaż nierealne, byłoby pomocne, gdyby programiści byli zmuszeni do pracy w roli sysadmin lub dba produkcji przed uwolnieniem się na całym świecie.

Tak wiele wyspecjalizowanych aplikacji, z którymi mam do czynienia, nie ma pojęcia o instalacji w środowisku zarządzanym lub popełnia okrucieństwa przy projektowaniu bazy danych.

1) Plik dziennika, który szczegółowo rejestruje błędy. lub dobry system śledzenia błędów, taki jak ELMAH.

2) Szczegółowa dokumentacja dotycząca instalacji, wdrażania i przewodnika SA.

3) Plus rzeczy wymienione powyżej z innych niesamowitych SA. :)

To wszystko, co mogę teraz wymyślić.

Książka Release It! ma niezły wybór horrorów o tym, co może pójść nie tak w produkcji. Lektura może dostarczyć inspiracji / pomysłów na projektowanie z myślą o operacjach. (Jest napisany przez Michaela Nygarda, który pracował zarówno po stronie rozwoju, jak i operacji.)

• Nie rozwijaj się bez specyfikacji
• Dokumentuj (lub upewnij się, że osoby, które to robią, robią to dokładnie)
• Nie bój się wspierać klienta (jako wyższy poziom wsparcia)

Z mojego doświadczenia wynika, że ​​największą różnicą jest to, że programiści pomyślą o wdrożeniu od pierwszego dnia. Gdy tylko zaczniesz wymyślać nową funkcję w środowisku produkcyjnym / klienta, zacznij myśleć o tym, jak zostanie ona wdrożona w tym środowisko i jak to będzie działać.

Gdy wejdą w proces rozwoju, nie jest za późno, ale może zająć trochę czasu, zanim będą w stanie zmienić perspektywę tak daleko; nie zdają sobie sprawy z tego, jak abstrakcyjnie oglądają bazę kodów, dopóki nie są zmuszeni do konfrontacji. Ich zdaniem jest to tylko „element”. Szczególnie interesujący jest sposób, w jaki zostanie on wdrożony w istniejącym środowisku, uruchamiając poprzednią (lub starszą!) Wersję oprogramowania. Dyskusje dotyczące wdrażania mogą mieć znaczący wpływ na sposób dostosowania architektury w celu dostosowania do nowej funkcji.

Coś, co lubię, czego jeszcze nie widziałem, można konfigurować. Jeśli masz aplikację korzystającą z dowolnego pliku konfiguracyjnego, skonfiguruj wszystko.
W mojej firmie napisałem prostą aplikację, która wyeksportuje fragment naszej bazy danych. W następnym tygodniu przepisałem go, aby umożliwić wyłączenie małej części. Od tego czasu co tydzień musiałem przepisywać części i przebudowywać je, aby zmienić małą funkcję. Właśnie dodałem plik konfiguracyjny xml, a teraz jest o wiele łatwiejsze do ponownego wdrożenia.
Uwielbiam pliki konfiguracyjne.

Chciałbym, aby programiści mieli lepsze oddzielenie od zadań związanych z kontrolą jakości. Myślę, że to miło, gdy programista jest w stanie stworzyć pewne przypadki testów jednostkowych dla projektu, nad którym pracuje, ale byłoby miło, gdyby testy te zostały przekazane do kontroli jakości. W rzeczywistości jest to miłe, gdy programiści udzielają niewielkiej pomocy inżynierom ds. Kontroli jakości, ponieważ ostatecznie przynosi to korzyść DEV.

Upewnij się, że jest obsługiwany: oprócz wszystkich innych wymienionych tutaj, spójrz na ten post na SO - https://stackoverflow.com/questions/205374/what-are-the-core-elements-to-include-in-support- dokumentacja/