Co jest wymagane, aby programiści mogli uruchomić własny serwer VM w środowisku korporacyjnym [zamknięte]

Ten scenariusz został również opublikowany na SO , z różnymi pytaniami dla różnych odbiorców - i cieszę się, że tak zrobiłem, ponieważ otrzymałem bardzo dobre odpowiedzi.

Staramy się wdrożyć środowisko programistyczne wykorzystujące wirtualizację dla małego zespołu 4 programistów w organizacji korporacyjnej. Umożliwiłoby to nam utworzenie oddzielnych środowisk programistycznych, testowych i testowych, a także dostęp do nowych systemów operacyjnych, które są wymaganiami dla systemów lub narzędzi, które oceniamy.

Zmieniliśmy przeznaczenie istniejącej maszyny klasy stacji roboczej, wrzuciliśmy 24 GB pamięci RAM i RAID-10 i wszystko szło dobrze, dopóki nie podjęliśmy próby dodania maszyny do domeny.

Teraz rozpoczynamy wojnę, z którą wszyscy deweloperzy korporacyjni od początku musieli walczyć - walkę o lokalną kontrolę środowiska programistycznego i testowego. Administratorzy sieci i IT zgłosili szereg obaw, począwszy od „ESX Server jest korporacyjnym standardem”, po serwery nie są dozwolone w sieciach VLAN klienta ”, aż do„ [wypełnij puste miejsce] nie jest zestawem umiejętności posiadanych obecnie w lokalna lub korporacyjna organizacja informatyczna ”.

Prawdopodobnie moglibyśmy uzasadnić sprzęt na poziomie produkcyjnym i formalne wsparcie IT (czytaj: moglibyśmy uzasadnić taką potrzebę, gdybyśmy musieli, ale zajęłoby to dużo czasu i wymagało by dużo bólu głowy) - ale prawdopodobnie zajęłoby to miesiące formalne uzyskanie zasobów IT przypisując to traktując to jako system produkcyjny - a nawet gdybyśmy to zrobili, prawdopodobnie stracilibyśmy lokalną kontrolę, jakiej chcemy.

Wyobrażam sobie, że wielu z was miało podobne problemy z programistami w przedsiębiorstwie w zakresie kontroli programistów w środowiskach nieprodukcyjnych, więc moje pytania są następujące:

1. Jakie argumenty przedstawili ci programiści, którzy przekonali cię, aby umożliwić istnienie tego rodzaju silosów w przedsiębiorstwach, które mają standardowe zasady sieci i bezpieczeństwa, które zasadniczo (i zrozumiałe) wykluczałyby tego rodzaju infrastrukturę nie (centralnie) zarządzaną?
2. Czy to tylko kwestia uzasadnienia technicznego lub biznesowego deweloperów i zapewnienia, że ​​nastąpi zarządzanie poprawkami i AV - czy raczej politycznej walki o kontrolę i własność?
3. Biorąc pod uwagę wybór, czy wolałbyś przejąć własność i wsparcie sprzętu / systemu operacyjnego, jednocześnie dając deweloperom prawa lokalnego administratora, czy pozwolić im całkowicie nimi zarządzać, jednocześnie upewniając się, że ustanawiają zarządzanie poprawkami / AV i obciążają ich odpowiedzialnością, czy mogą powodować problemy?
4. Jeśli skutecznie zablokowałeś programistom lokalną kontrolę nad „nieuczciwymi serwerami” w Twojej infrastrukturze, czy programiści właśnie to zrobili, czy też (lub Ty) przenieśliście środowisko programistyczne do rozłączonej sieci VLAN / całkowicie oddzielnej sieci?

Kilka założeń ograniczających zakres tego pytania:

1. Aby powtórzyć, dotyczy to środowiska programistycznego - nie są wymagane żadne obciążenia produkcyjne ani obsługa. Nic nie jest dostępne z zewnątrz.
2. To nie jest święta wojna Hyper-V vs. ESX (byłoby nam dobrze - ale Hyper-V został wybrany, ponieważ jest „darmowy” z MSDN do tych celów [tak, VMWare też ma darmowe narzędzia - ale dobre zarządzanie narzędzia na ogół nie są] i łatwiej byłoby nimi zarządzać lokalni programiści w „Sklepie Microsoft”) - więc argumenty za lub przeciw którymkolwiek z nich są poza zakresem tego pytania.
3. Zespół deweloperów zapewnił już, że może zarządzać łatkami i programami antywirusowymi lub zintegrować je z istniejącymi systemami korporacyjnymi, jeśli IT je wesprze - ale z pewnością nie ma znaczenia, czy jesteś skłonny to zaakceptować.

Po pierwsze, widzę kilka powodów, dla których twoi administratorzy mają rację, by odpychać:

• Dział IT odpowiada również za zgłaszanie takich spraw, jak zarządzanie poprawkami, oprogramowanie antywirusowe, zgodność z PCI, coroczne (lub częstsze) audyty bezpieczeństwa itp. Nie chodzi tylko o zapewnienie, że zostanie to załatwione, ale także o możliwość aby to udowodnić na zewnątrz.

  Jako przykład prowadzę sieć w małym college'u i mamy laboratorium fizyki z kilkoma maszynami do gromadzenia danych do eksperymentów studenckich. Jedyne, co robią, to zbieranie danych z instrumentu naukowego i wydrukowanie wyników (bezpośrednio podłączonej drukarce), aby uczeń mógł je przeanalizować i przekazać instruktorowi. Nigdy nie są dostępne w Internecie - nawet aktualizacje AV i Windows są stosowane przez sieć lokalną. Jedynym powodem, dla którego są podłączeni do sieci i w ogóle uruchamiają oprogramowanie AV, są wyraźne cele zgłoszenia mojemu oprogramowaniu monitorującemu, że nadal istnieją i są aktualne. To głupie, jak oni w rzeczywistości być bardziej bezpieczne, aby usunąć połączenie sieciowe, ale po raz pierwszy zostały opłacone z grantu edukacyjnego i tak są moje wymagania w zakresie sprawozdawczości.

• Czy ci się to podoba, czy nie, serwer deweloperów jest systemem produkcyjnym z punktu widzenia programistów. Daj mu może miesiąc, a programiści będą mieli trudności z wykonaniem pracy, jeśli przestanie działać z powodu skonfigurowanych procesów, które zakładają, że serwer jest dostępny. Unikanie / ograniczanie sytuacji, w których pracownicy są bezczynni z powodu awarii technologii, jest głównym powodem, dla którego firmy nadal korzystają ze scentralizowanych działów IT.
• Jeśli „ESX Server to Enterprise Standard”, musisz tego przestrzegać. W tej chwili istnieją znaczne różnice między tym, jak robią to hyper-v, vmware, xen i inni, i nie można założyć, że maszyna zbudowana dla jednego działa dobrze na drugim. Jeśli masz zamiar to zrobić, dział IT będzie musiał w pewnym momencie pomóc w zarządzaniu nim, a nie będzie musiał konwertować go na oprogramowanie vmware po pojawieniu się kłopotów na komputerze, które mogą powodować problemy.
• Któregoś dnia urządzenie to zestarzeje się i będzie wymagało regularnej konserwacji lub skonfigurowania standardowego cyklu wymiany. Nawet nowe serwery czasami mają części bum. Ta sytuacja prawie zawsze ląduje na kolanach IT dopiero po tym, jak coś się zepsuje, co uniemożliwi ludziom wykonywanie pracy. Przejmując odpowiedzialność za serwer wcześnie, dział IT może wykonać znacznie lepszą pracę, unikając nieplanowanych przestojów.
• Ten jest osobisty, ale mogę Wam powiedzieć, że ostatnią rzeczą, której chcę w mojej sieci, jest inny pulpit udający serwer. Miałem dość tych ostatnich kilku lat, aby przetrwać całe życie.

To powiedziawszy, IT musi być w stanie wesprzeć tę inicjatywę. Nie wystarczy, że powie „Nie”. Rzuć im wyzwanie, aby zaproponowali alternatywę, która zaspokoi Twoje (bardzo realne) potrzeby. Jedyną sytuacją polityczną powinno być to, że ich alternatywa prawdopodobnie będzie miała wyższą cenę za naklejkę (ponieważ planują koszty, których jeszcze nie widać), a więc pytanie będzie, kto będzie musiał za to zapłacić. IT nie będzie chciało, bo nie zaplanowało na to budżetu, ale będziesz bał się, ponieważ to 6 razy więcej niż wydałeś na rozwiązanie, z którego byłeś zadowolony (na razie).

Wygląda na to, że próbujesz biec, zanim będziesz mógł chodzić. Chcesz odnowić swój proces rozwoju. Jako były programista uważam, że to świetnie. Ale nie wyrzucaj tylko kilku maszyn wirtualnych i „środowisk” (tj .: dev, stage, qa itp.). Zaplanuj, jak będą wyglądać nowe procesy - w jaki sposób programiści wykonają pracę. Czy użyjesz ciągłej integracji? Zautomatyzowane kompilacje? Używasz oprogramowania do ich obsługi? Czy programiści będą mogli przenieść kod do wersji produkcyjnej lub programowej, czy tylko QA będzie mieć taką możliwość? Potrzebujesz osobnej inscenizacji? Co z dwiema gałęziami deweloperów (jedną dla vNext, drugą dla błędów z vCurrent)?

Możesz potrzebować serwera tylko po to, aby kierownik ds. Rozwoju lub menedżer mógł to wszystko rozwiązać, ale jeśli tak, to musi to być pierwszy krok, a konfiguracja i wstępne projektowanie procesu muszą zostać wykonane, zanim programiści wezmą go w swoje ręce posługiwać się.

1) Jakie argumenty przedstawili ci programiści, którzy przekonali cię, aby umożliwić istnienie tego rodzaju silosów w przedsiębiorstwach, które mają standardowe zasady sieci i bezpieczeństwa, które ogólnie (i zrozumiałe) wykluczałyby tego rodzaju infrastrukturę nie (centralnie) zarządzaną ?

Żadne - głównie dlatego, że nie pełnię roli kierowniczej w mojej organizacji, więc żadna z tych „rzeczy politycznych” tak naprawdę mnie nie dotyczy. Jedynym argumentem, który naprawdę mnie przekonałby, jest zezwolenie na coś, co jest wyraźnie sprzeczne z polityką sieci i wyłączone zarówno z kontroli zespołu operacyjnego, jak i widoczności, to przerwa powietrzna i list CYA od szefa mojego szefa.

Nie chodzi o to, że tak naprawdę chciałbym powiedzieć „Nie”, po prostu nie ma dobrego sposobu, aby zakończyć to dobrze z punktu widzenia zespołu operacyjnego.

1. W rezultacie serwery są zarządzane przez osoby, których podstawowym zestawem umiejętności nie jest zarządzanie serwerami w sieci, które nie mają widoczności całej sieci i związanego z nią obszaru problemów. Nie chodzi tylko o polityczną troskę o „ochronę” murawy; jako banalny przykład wyobraź sobie, co się dzieje, gdy programista włącza DHCP z jakiegoś powodu.
2. W końcu zarządzamy dla nich serwerami zespołu programistów. Jest to bałagan z przeciwnego powodu. Deweloperzy stale denerwują się, że łatamy to (niszcząc coś, o czym wiedzą, ale nie wiemy) lub walczą o włączenie funkcji, które z różnych dobrych powodów nie powinny być włączone. Szybko zamienia się to w impas, w którym zespół operacyjny czuje się obciążony i nękany, a zespół programistów czuje się sfrustrowany i ignorowany.
3. Są to konsekwencje polityczne - ponieważ wtedy musisz wyjaśnić innemu działowi, dlaczego programiści są „specjalni” i dlaczego są zwolnieni z zasad sieciowych.

2) Czy to tylko kwestia uzasadnienia technicznego lub biznesowego deweloperów i zapewnienia, że ​​nastąpi zarządzanie poprawkami i AV - czy raczej politycznej walki o kontrolę i własność?

Nie sądzę, że programiści muszą przedstawić uzasadnienie biznesowe - jest całkiem jasne, że programiści musieli się rozwijać, a aby to zrobić, potrzebują pewnego rodzaju środowiska programistycznego. Jeśli chodzi o zarządzanie poprawkami i AV - to zadanie zespołu operacyjnego, a my upewnimy się, że zostało wykonane. Nie jest tak, że naszym zdaniem programiści nie mogą tego zrobić. Po prostu nie ufamy, że robisz to dobrze - administratorzy systemu pozostają administratorami systemu, ponieważ nie ufają, że zrobią coś dobrze, więc nie ma w tym nic osobistego. Oczywiście istnieje oczywista kwestia polityczna polegająca na odczuciu, że ktoś „wykonuje swoją pracę”, ale to nie jest tak naprawdę problem techniczny, a zatem nie wchodzi w zakres SF.

3) Biorąc pod uwagę wybór, czy wolisz przejąć własność i wsparcie sprzętu / systemu operacyjnego, dając deweloperom uprawnienia lokalnego administratora, czy pozwolić im całkowicie nimi zarządzać, jednocześnie upewniając się, że ustanawiają zarządzanie poprawkami / AV i obciążają ich odpowiedzialnością, jeśli spowodują problemy?

Ani z powodów wymienionych powyżej.

4) Jeśli skutecznie zablokowałeś programistom lokalną kontrolę nad „nieuczciwymi serwerami” w Twojej infrastrukturze, czy programiści właśnie to zrobili, czy też (lub Ty) przenieśliście środowisko programistyczne do odłączonej sieci VLAN / całkowicie oddzielnej sieci?

Szczelina powietrzna. Najlepszym sposobem na poradzenie sobie z tą sytuacją jest zapewnienie programistom środowiska (i kontrola nad nim), a następnie przerwa powietrzna lub użycie innej niezawodnej metody oddzielenia go od sieci. Zasadniczo w ten sposób obsługujemy publiczne Wi-Fi. Chcesz usługi Wi-Fi? Pewnie. Płacisz za połączenie sieciowe, my będziemy zarządzać WAP, ale nigdy nie dotknie naszej sieci. Przepraszam. Twoje potrzeby są tylko jedną z setek. Istnieją inne obawy, które musimy wziąć pod uwagę.

Nie chcesz zajmować się odmawianiem, ponieważ programiści (którzy są szczególnie sprytni technicznie) znajdą sposoby na uzyskanie tego, czego chcą. Zapewnij im środowisko odpowiadające ich potrzebom, spraw, by byli szczęśliwi, a następnie znajdź sposób, aby zapobiec dotykaniu reszty Twojej sieci biznesowej wszystkiego, co robią w środowisku programistycznym.

TL; DR: Dałbym ci serwer z dowolną platformą wirtualizacji, którą chcesz w oddzielnej sieci fizycznej lub VLAN. Dostęp do środowiska programistycznego miałby jeden host bastionowy, który zespół operacyjny kontrolowałby i monitorował. Co robisz z tym swoją firmą - nie będzie obsługiwana, ale zapewniamy porady i pomoc w miarę czasu po stronie administracyjnej serwera.

Jeśli przyszedłeś do mnie z maszyną klasy stacji roboczej załadowaną do rękojeści z konsumencką pamięcią RAM, dyskami twardymi klasy konsumenckiej, zasilaczem klasy konsumenckiej i macierzą RAID klasy konsumenckiej, odmówiłbym umieszczenia jej również w sieci serwerów.

Jest wiele rzeczy, które musisz zrozumieć, umieszczając coś takiego na serwerze VLAN.

1. Serwer VLAN może równie dobrze być strefą DMZ. W strefie DMZ nie umieszcza się niczego , co nie jest utwardzone i zabezpieczone. To tylko maszyna, którą im podałeś, nie mają pojęcia, co z tym zrobiliście. Oznacza to również regularne łatanie i aktualizacje, co oznacza centralne zarządzanie. Jestem pewien, że jak cholera nie zamierzam zalogować się na każdym niezarządzanym serwerze i ręcznie zastosować łatek.

2. Komponenty w tej maszynie ulegną awarii. Obiecuję. W ciągu 6 lub 12, 24 miesięcy wszystko pójdzie w górę. Gdzie są zatem kopie zapasowe? Och, nie ustawiłeś ich? Ale myślałem, że to serwer? Och, to serwer, który ktoś zapewnił? ... i gra o winy zaczyna się od nowa

3. Kto weźmie odpowiedzialność, gdy się rozbije i gówno uderzy w wentylator? W większości organizacji „powierzyłem opiekę deweloperowi” nie będzie latać.

4. Gdzie zamierzają to położyć? Wszystkie serwery są obecnie montowane w szafie, a umieszczenie wieży w szafie marnuje miejsce, a ich szafy mogą nie być do tego przeznaczone.

Dlatego dział IT jest bardzo uzasadniony, aby nie umieszczać tego losowego komputera w sieci serwerów.

Jednak zadaniem działów IT jest upewnienie się, że TY możesz właściwie wykonać SWOJĄ pracę. Muszą upewnić się, że masz to, czego potrzebujesz, kiedy tego potrzebujesz. Jeśli masz oprogramowanie, które firma musi kontynuować, musi zapewnić platformę, na której będzie działać. To ich opis pracy. Ale musisz upewnić się, że mają informacje potrzebne do wykonywania swojej pracy.

Gdybyś przyszedł do mnie w mojej organizacji i powiedział mi, że zaczynasz nowy projekt, dałbym ci trzy maszyny wirtualne: Dev, Live i Staging. Będziesz mieć pełne prawa administratora do Deva, a my omówimy, czego potrzebujesz, aby wykonać swoją pracę dla pozostałych dwóch. Jeśli potrzebujesz do nich pełnych uprawnień administratora i możesz to uzasadnić, dostaniesz je. Wdrożyliśmy nasze wdrożenie VM. VMWare sprawia, że ​​jest to niezwykle proste - wdrożenie zajmuje tylko około 5 minut na maszynę wirtualną.

Wygląda na to, że Twój dział IT cierpi na to, na co cierpi każdy dział IT w dużej firmie. Budowanie małych zamków i obrona ich życiem, nie wpuszczanie innych, bycie szefem itp. Jako ktoś, kto codziennie zajmuje się działami informatycznymi innych ludzi, cały czas to widzę. I to jest frustrujące.

Podstawowym faktem jest jednak to, że zmiana musi nastąpić z poziomu działu IT i musi zostać zainicjowana z góry. A jeśli uda ci się uświadomić IT, że nie są one siłą dla siebie (ponieważ większość z nich nie generuje dochodu dla ich firm, może to być całkiem klapsa w twarz) i że są tam, aby wspierać istniejący personel i rozwinąć działalność, wtedy okaże się, że twoje pytania stają się nieistotne, ponieważ wszyscy będą grać szczęśliwe rodziny.

Dlaczego chcesz go dodać do domeny? Innymi słowy, która lepiej odpowiada na pytanie: możesz założyć laboratorium, które będzie robić, co tylko chcesz, o ile nie jest podłączone do korporacyjnej sieci LAN. (Jeśli potrzebny dostęp do internetu, może dostać DMZ-ED VLAN, to nie powinno być problemem, zwłaszcza jeśli tylko używając go, aby przejść się , jak do pobrania).

To jedna z wielu wielu różnych odpowiedzi na pytanie.

Otrzymasz Mnóstwo odpowiedzi tutaj, za i przeciw programistom mającym dostęp administratora do dowolnej części środowiska (prawdopodobnie głównie przeciwko), ale oto sedno:

Grupa sysadmin ma za zadanie utrzymywanie działania systemów produkcyjnych w sposób stabilny, stabilny i bezpieczny oraz jest odpowiedzialna za zapewnienie, że systemy te zapewniają usługi, za które firma płaci (ponieważ płaci za nie) na oczekiwanych poziomach.

Podobnie zespół programistów ma za zadanie świadczyć usługi dla firmy (sieć, aplikacje itp.), Aczkolwiek na innej arenie. Walka o kontrolę nad środowiskiem programistycznym przynosi efekt przeciwny do zamierzonego i nie służy żadnemu pożytecznemu celowi żadnej ze stron.

Pracuję na małym ISV ​​/ ASP. Mamy jednego programistę i jednego administratora systemu (mnie). Mamy relacje oparte na wzajemnym szacunku i zaufaniu. Musimy pracować jako zespół, aby pomóc w osiągnięciu nadrzędnych celów firmy. Daję deweloperowi pełny, nieograniczony dostęp do jego środowiska programistycznego, które obejmuje stacje robocze i serwery. Zarządzam systemami deweloperskimi w zakresie bezpieczeństwa, aktualizacji, AV i sprzętu, a program zajmuje się resztą. Kiedy jego kod jest gotowy do produkcji, przekazuje go mi, pomaga w każdej potrzebnej konfiguracji i cofa się. Zapewniamy sobie wzajemną pomoc.

Deweloperzy powinni być panami środowiska programistycznego, a Sysadmini powinni być panami środowiska produkcyjnego, w rozsądnych granicach, z rozsądnymi kontrolami, równowagą i kontrolą. Kiedy którakolwiek ze stron musi „przejść na drugą stronę”, powinna ona współpracować i współpracować z partią „panującą” pod ich nadzorem i kierownictwem.

Po pierwsze, moje doświadczenie jest ściśle w mniejszej organizacji, ale ten problem pojawia się w firmach każdej wielkości, więc ...

1.  What arguments have your developers made that won you over to
allow these types of silos to exist within enterprises which have
standard network and security policies in

Z mojego punktu widzenia jedynym argumentem, który muszą przedstawić programiści, jest „potrzebujemy tego”. Gdyby przyszli do mnie jako pierwsi, spróbowałbym zrozumieć ich potrzeby i zobaczyć, co moglibyśmy wypracować. Ale ostatecznie, jeśli powie „potrzebujemy tego”, dałbym im korzyść z wątpliwości i zaufania, że ​​wiedzą, co robią.

Ale to dopiero początek - to jest „pro” strona równania. „Con” to miejsce, w którym wchodzimy do sporu…

2. Is this just a matter of the developers making a technical or
business justification

Z wyjątkiem tego, że „just” jest niesamowitym niedopowiedzeniem, tak, jeśli programiści mogą przedstawić uzasadnienie techniczne i biznesowe, nie byłoby problemu. Inni tutaj i na programistach.SE (gdzie migrowano twoje pytanie SO) wskazali mnóstwo pułapek w twojej konfiguracji, więc ich nie powtórzę. Jeśli wymyślisz plan rozwiązania wszystkich tych problemów i wszelkich innych, o których myśli Twój dział IT, i uzasadnisz WSZYSTKIE koszty, to warto kontynuować.

3.  Given the choice, would you prefer to take ownership and support
of the hardware/OS while giving devs local admin rights,

To nie jest starter, nie możesz mieć dwóch grup o różnych celach i obowiązkach, próbujących zarządzać tymi samymi systemami. Nie tylko źle się skończy, zacznie źle i skończy się rozlewem krwi.

(more of 3.) ... or let them manage it entirely, while ensuring that
they institute patch management/AV and charging them with
responsibility should they cause problems?

Myślę, że jest to objęte moją odpowiedzią na 2 .: to są szczegóły techniczne, na które musieliby wymyślić rozwiązania.

4.  If you successfully blocked developers from having local control
of "rogue servers" on your infrastructure, did the developers just
make due or did they (or you) move the development environment to a
disconnected VLAN/entirely separate network?

Zgadzam się z kce: „Szczelina powietrzna”

Jeśli potrafią uzasadnić dodatkowe obciążenie, które podejmują (stając się administratorami swojego środowiska), programiści mogą mieć własną mini-sieć, w której mają swobodę, ALE to jest całkowicie poddane kwarantannie: nic nie dotyka reszty sieci. Muszą więc przedstawić bardziej techniczne i biznesowe uzasadnienia, np. „Jak zamierzamy wykonać kopię zapasową krytycznych danych?”

Ponownie muszę zgodzić się z kce: „Administratorzy systemu pozostają administratorami systemu, ponieważ nie ufają, że zrobią coś dobrze”. Naszym zadaniem jest budowanie najbardziej niezawodnych systemów, które możemy wykonać z niewiarygodnych komponentów, więc każda propozycja zawierająca połowę tuzin rzeczy, o których doświadczony sysadmin wie, że są niewiarygodne, spotka się z silną negatywną reakcją.

Z odpowiedzi i komentarzy tutaj i na programmers.se, myślę, że jest jasne, że są aspekty, których nie wziąłeś pod uwagę. Chociaż potrwa to dłużej, myślę, że naprawdę musisz porozmawiać z informatykami i przedstawić różne rzeczy: „oto co musimy zrobić, czy jest jakiś sposób na zintegrowanie tego z istniejącą infrastrukturą i operacjami?”

Ogólny problem w twoim i milionach podobnych przypadków jest następujący:

1) Rozmyta odpowiedzialność - nie ma bezpośredniego związku między działaniami pracownika korporacyjnego a jego zyskami. Płacą go za miesiąc, a nie za efekty, które są trudniejsze do zmierzenia, tym większa jest organizacja. Dotyczy to bezpieczeństwa, menedżerów itp. Jeśli sparaliżują twoją pracę, to ich nie obchodzi.

2) Decydenci i bezpieczeństwo zwykle mają niewielką lub żadną wiedzę na temat programowania. Nie mogli zrozumieć, że paraliżują twoją pracę, nawet jeśli by ich to obchodziło (co zwykle nie ma zastosowania).

3) Preferowanym profilem psychologicznym dla pracy w ochronie jest osobowość paranoiczna lub zaburzenie obsesyjno-kompulsyjne. Ci ludzie widzą spisek wszędzie. Jeśli programiści chcą czegoś takiego, jak nowy serwer, z pewnością chcą go wykorzystać do kradzieży danych firmowych i opublikowania ich w WikiLeaks lub sprzedaży do Korei Północnej.