Welche Sysadmin-Dinge sollte jeder Programmierer wissen?

Als Programmierer halten wir Sysadmins für selbstverständlich. Die wenigen Male, in denen ich keinen guten Systemadministrator hatte, haben mich wirklich zu schätzen gelernt, was ihr tut. Wenn wir uns in eine Umgebung ohne Systemadministrator begeben, welche Worte der Weisheit können Sie uns anbieten?

Ich würde anfangen mit:

1. Haben Sie immer ein Backup-System. Noch besser, wenn es eine Geschichte hat.
2. Betrachten Sie einzelne Fehlerquellen und wie Sie mit ihnen umgehen können, wenn sie versagen.
3. Abhängig von der Anzahl der beteiligten Computer erleichtert die Suche nach einer Möglichkeit, ein Standard-Image für mehrere Computer zu erstellen, das Leben aller - nein, es funktioniert auf meinen Computern, da diese und jene Programme normalerweise nicht installiert sind.
4. Dokumentieren Sie alles, schon deshalb, weil Sie vergessen werden , wie Sie etwas eingerichtet haben.
5. Bleiben Sie über Sicherheitsupdates auf dem Laufenden.

<hier einen großen Haftungsausschluss einfügen>

Einige davon wurden bereits erwähnt, aber es lohnt sich, sie zu wiederholen.

Dokumentation:

• Alles dokumentieren. Wenn Sie noch keines haben, installieren Sie ein Unter-dem-Radar-Wiki, aber stellen Sie sicher, dass Sie es sichern. Beginnen Sie mit dem Sammeln von Fakten, und eines Tages wird sich ein großes Bild bilden.

• Erstellen Sie Diagramme für jeden logischen Block und halten Sie sie auf dem neuesten Stand. Ich konnte nicht zählen, wie oft mich eine genaue Netzwerkkarte oder ein Clusterdiagramm gerettet hat.

• Behalten Sie die Erstellungsprotokolle für jedes System bei, auch wenn es sich nur um Befehle zum Kopieren und Einfügen handelt.

• Installieren und konfigurieren Sie beim Erstellen Ihres Systems Ihre Apps, testen Sie die Funktionsweise und führen Sie das Benchmarking durch. Wischen Sie nun die Datenträger ab. Ernsthaft. "dd" das erste Megabyte von der Vorderseite der Festplatten oder machen Sie die Box auf andere Weise nicht mehr bootfähig. Die Uhr tickt: Beweisen Sie, dass Ihre Dokumentation von Grund auf neu erstellt werden kann (oder, noch besser, beweisen Sie, dass Ihr Kollege nur mit Ihrer Dokumentation arbeiten kann). Dies ist die Hälfte Ihres Disaster Recovery-Plans.

• Jetzt haben Sie die erste Hälfte Ihres Disaster Recovery-Plans. Dokumentieren Sie den Rest. Wie Sie den Status Ihrer Anwendung wiederherstellen (Dateien vom Band wiederherstellen, Datenbanken von Speicherauszügen neu laden), Hersteller- / Support-Details, Netzwerkanforderungen, wie und wo Sie Ersatzhardware erhalten - alles, was Sie sich vorstellen können, hilft dabei, Ihr System wieder auf den neuesten Stand zu bringen.

Automatisierung:

• Automatisieren Sie so viel wie möglich. Wenn Sie dreimal etwas tun müssen, stellen Sie sicher, dass der zweite Teil für die Entwicklung Ihrer Automatisierung aufgewendet wird, damit der dritte Teil vollständig automatisiert wird. Wenn Sie es nicht automatisieren können, dokumentieren Sie es. Es gibt Automatisierungssuiten - prüfen Sie, ob Sie sie für Sie zum Laufen bringen können.

Überwachung:

• Anwendungsinstrumentierung ist reines Gold. Die Möglichkeit, Transaktionen zu beobachten, die durch das System laufen, erleichtert das Debuggen und die Fehlerbehebung erheblich.

• Erstellen Sie End-to-End-Tests, die nicht nur beweisen, dass die Anwendung lebt, sondern auch wirklich das tut, was sie soll. Punkte liegen bei Ihnen, wenn sie zu Alarmierungszwecken in das Überwachungssystem eingebunden werden können. Dies dient der doppelten Pflicht; Abgesehen davon, dass die App funktioniert, werden Systemaktualisierungen erheblich vereinfacht (Systemüberwachung meldet Grün, Aktualisierung war erfolgreich, Zeit, nach Hause zu gehen).

• Benchmarking, Überwachung und Erfassung von Metriken zu allem, was dazu nötig ist. Anhand von Benchmarks können Sie erkennen, wann etwas den magischen Rauch ausströmen lässt. Monitoring sagt Ihnen, wann es hat. Metriken und Statistiken erleichtern es, neue Kits (mit frischem magischem Rauch) über die Verwaltung zu beziehen.

• Wenn Sie kein Überwachungssystem haben, implementieren Sie eines. Bonuspunkte, wenn Sie die oben genannten End-to-End-Tests tatsächlich durchführen.

Sicherheit:

• "chmod 777" (auch bekannt als "Zugriff / Privilegien gewähren") ist niemals die Lösung.

• Unterzeichnen Sie das Prinzip des kleinsten Teils; Wenn es nicht installiert, kopiert oder auf andere Weise auf der Festplatte gespeichert ist, kann es nicht gefährdet werden. Die Installation des Betriebssystems und der Software "Kitchen Sink" macht das Leben während der Erstellungsphase möglicherweise einfacher, aber Sie müssen später dafür bezahlen.

• Wissen, wofür jeder offene Port auf einem Server ist. Überprüfen Sie sie regelmäßig, um sicherzustellen, dass keine neuen angezeigt werden.

• Versuchen Sie nicht, einen gefährdeten Server zu säubern. es muss von Grund auf neu aufgebaut werden. Stellen Sie mit frisch heruntergeladenen Datenträgern einen Ersatzserver wieder her, und stellen Sie nur die Daten von Sicherungen wieder her (da die Binärdateien möglicherweise beschädigt sind), oder klonen Sie den beschädigten Host an einen für die Analyse isolierten Ort, damit Sie dasselbe Kit erneut erstellen können. Es gibt einen ganzen legalen Albtraum, also irre auf der Seite der Bewahrung, falls du legale Wege beschreiten musst. (Anmerkung: IANAL).

Hardware:

• Niemals davon ausgehen, dass irgendetwas das tut, was auf der Schachtel steht. Beweisen Sie, dass es das tut, was Sie brauchen, für den Fall, dass dies nicht der Fall ist. Sie werden feststellen, dass Sie häufiger sagen, dass es fast funktioniert, als Sie es erwarten würden.

• Sparen Sie nicht bei der Remote-Hardwareverwaltung. Serielle Konsolen und Lights-Out-Management sollten als obligatorisch angesehen werden. Bonuspunkte für ferngesteuerte Steckdosenleisten für Zeiten, in denen Sie keine Optionen mehr haben.

(Übrigens: Es gibt zwei Möglichkeiten, um ein Problem um 3 Uhr morgens zu beheben. Eine besteht darin, warm zu sein und über ein VPN in Ihrem Schlafanzug an einem Laptop zu arbeiten. Die andere besteht aus einer dicken Jacke und einer Fahrt zum Rechenzentrum / Büro. Ich weiß, welche ich bevorzugen.)

Projektmanagement:

• Binden Sie die Personen ein, die das System vom ersten Tag des Projektlebenszyklus an warten. Die Vorlaufzeiten für Kit- und Brain-Time können und werden überraschen, und es besteht kein Zweifel, dass sie Standards oder Anforderungen haben (sollten?), Die zu Projektabhängigkeiten werden.

• Die Dokumentation ist Teil des Projekts. Sie werden nie Zeit haben, das Ganze aufzuschreiben, nachdem das Projekt geschlossen und das System auf Wartung umgestellt wurde. Stellen Sie daher sicher, dass es zu Beginn als Aufwand in den Zeitplan aufgenommen wird.

• Implementieren Sie die geplante Veralterung vom ersten Tag an in das Projekt und starten Sie den Aktualisierungszyklus sechs Monate vor dem in der Projektdokumentation angegebenen Ausschalttag.

Server haben eine definierte Lebensdauer, wenn sie für den Einsatz in der Produktion geeignet sind. Das Ende dieser Lebensdauer ist in der Regel definiert als der Zeitpunkt, an dem der Verkäufer beginnt, mehr für die jährliche Wartung in Rechnung zu stellen, als für die Auffrischung des Kits. Je nachdem, welcher Zeitraum kürzer ist, sind es etwa drei Jahre. Nach dieser Zeit eignen sie sich hervorragend für Entwicklungs- / Testumgebungen, aber Sie sollten sich nicht darauf verlassen, dass sie das Geschäft führen. Wenn Sie die Umgebung nach 2 1/2 Jahren erneut besuchen, haben Sie genügend Zeit, um die erforderlichen Management- und Finanzaufgaben für die Bestellung eines neuen Kits zu erledigen und eine reibungslose Migration durchzuführen, bevor Sie das alte Kit an den großen Anbieter in den Himmel schicken.

Entwicklung:

• Stellen Sie sicher, dass Ihre Entwicklungs- und Staging-Systeme der Produktion ähneln. VMs oder andere Virtualisierungstechniken (Zonen, LDOMs, vServer) vereinfachen das Klonen von Produktionen, die in jeder Hinsicht leistungsfähig sind.

Backups

• Daten, die Sie nicht sichern, sind Daten, die Sie nicht möchten. Dies ist ein unveränderliches Gesetz. Stellen Sie sicher, dass Ihre Realität dazu passt.

• Backups sind schwieriger als sie aussehen. Einige Dateien sind offen oder gesperrt, während andere stillgelegt werden müssen, um eine Wiederherstellung zu erhoffen, und alle diese Probleme müssen behoben werden. Einige Sicherungspakete verfügen über Agenten oder andere Methoden, um mit geöffneten / gesperrten Dateien umzugehen, andere Pakete nicht. Das Speichern und Sichern von Datenbanken auf die Festplatte zählt als eine Form des "Stilllegens", ist jedoch nicht die einzige Methode.

• Backups sind wertlos, sofern sie nicht getestet wurden. Ziehen Sie alle paar Monate ein zufälliges Band aus den Archiven, und vergewissern Sie sich, dass es tatsächlich Daten enthält und die Daten konsistent sind.

Und am wichtigsten...

Wählen Sie Ihre Fehlermodi aus, oder Murphy wird ... und Murphy arbeitet nicht nach Ihrem Zeitplan.

Entwerfen Sie für den Ausfall, dokumentieren Sie die entworfenen Schwachstellen jedes Systems, was sie auslöst und wie sie wiederhergestellt werden können. Es wird den Unterschied ausmachen, wenn etwas schief geht.

Gehen Sie nicht davon aus, dass es einfach ist. Ich kenne viele Programmierer, die denken, dass sie nur, weil sie IIS oder Apache auf ihrer Dev-Box einrichten können, eine Webfarm betreiben können. Verstehen Sie, was der Job beinhaltet, und führen Sie Ihre Recherchen und Planungen durch. Denken Sie nicht nur, dass die Sysadmin-Arbeit die einfache Sache ist, die Sie in 10 Minuten tun können, um Ihre App bereitzustellen.

• Stellen Sie fest, dass viele der Server und / oder Netzwerkgeräte, die sie tendenziell verwenden, Kindern aus einer zweiten Familie sehr ähnlich sind. Das sind ihre Babys. Sie kümmern sich um sie, helfen ihnen, wenn sie krank sind, und überwachen sie wachsam auf Probleme. Das sollte nicht so sein, aber nach vielen Jahren ist es oft so . Denken Sie daran, wenn Sie ihnen Ihre Bedenken hinsichtlich einer nicht ordnungsgemäßen Funktion der Geräte oder der Erwartungen mitteilen. Und wenn Sie eine Antwort erhalten, die Sie nicht verstehen, filtern Sie sie durch diese Weltanschauung.
• Seien Sie auf guten Arbeitsbedingungen. Klingt frech, ist aber Gold wert. Eines Tages brauchen Sie einen besonderen Gefallen. Und eines Tages wird dieser Sysadmin gerne alles daran setzen, Ihnen das Leben ein wenig zu erleichtern, nur dieses eine Mal.
• Diese Arbeitsbeziehung geht in beide Richtungen. Wenn der Sysadmin sehr beschäftigt ist und Sie das Leben ein wenig erleichtern könnten, indem Sie ein kleines Skript oder Programm schreiben, dann tun Sie es! Sie werden es mehr zu schätzen wissen, als Sie wissen.
• Sei sehr klar. "Das ist scheiße" ist nicht so klar wie "eine unterbrochene Netzwerkverbindung zu haben ist ein bisschen ärgerlich, gibt es eine Chance, sich das anzuschauen?"
• Wenn Sie glauben, dass Ihre App skaliert, fragen Sie den Administrator, bevor Sie davon ausgehen , dass dies der Fall ist. Sie "sehen" möglicherweise etwas, das Sie nicht sehen, oder wissen etwas über die Leistungsgrenzen der Geräte, auf denen Sie bereitstellen werden.
• Wenn Ihre App optimiert werden muss, es sich aber anscheinend nicht um ein Codeproblem handelt, fragen Sie gut nach der Leistung der Server. Sysadmins kümmern sich liebevoll um ihre Maschinen und sind nicht erfreut, wenn sie "krank" oder "schlecht benommen" sind. Wenn Sie freundlich fragen, wird eine kranke Maschine umgedreht (oder repariert / ersetzt).
• (Wie an anderer Stelle erwähnt) Dokumentieren Sie die Einstellungen, die Sie verwenden, und warum Sie sie verwenden. Nur "set checkbox X" oder "uncomment config file line Y" zu haben, hilft nicht. Möglicherweise haben Sie die Option festgelegt, mit der alle Ihre Daten beim nächsten Neustart gelöscht werden, sofern Sie dies wissen.
• Wenn Sie nicht die Zeit haben, die Einstellung auf Papier zu dokumentieren, versuchen Sie, sie nach Möglichkeit im System zu dokumentieren. Bei Konfigurationsdateien sollte dies fast Standard sein - jede Einstellungsänderung sollte mit einem Datumsstempel versehen sein, mit Initialen, dem erwarteten Effekt dieser Einstellung und dem Grund, warum sie geändert wurde (siehe vorherigen Aufzählungspunkt). Diese kleine Angewohnheit hat meinen Speck während der Crunch-Zeit mehr als einmal gerettet. "Warum haben wir das gemacht?" "Weil wir Richtlinie X vorgeschrieben haben und die Einstellung Y uns das Verhalten gibt, das wir für Richtlinie X benötigen".
• Bier. Oder Cola. Oder sogar Wasser. Getränke sind immer willkommen. Sysadmin sein ist durstige Arbeit.

Sicherheit ist kein nachträglicher Gedanke. Während eine gehackte App den Programmierer inkompetent aussehen lassen kann, ist es (zumindest) ein verlorenes Wochenende, an dem ein Systemadministrator Backups überprüft, bereinigt und / oder wiederherstellt.

In diesem Fall sollten Sie Backups nicht als Versionskontrolle behandeln. Sie sind für die Notfallwiederherstellung gedacht und nicht für die Wiederherstellung Ihres Codes, da Sie vergessen haben, was Sie geändert haben.

Hören Sie auf, Windows Updates blind für fehlerhaften Code zu beschuldigen. Es ist mir egal, dass es funktioniert hat, sagen Sie mir, warum es jetzt nicht funktioniert - dann können wir sehen, wessen Schuld es ist.

Debuggen von Netzwerkproblemen und Beobachten der Ausführung Ihres Programms mit Sysadmin-Tools. Als Programmierer, der mit der Systemadministration begonnen hat, bin ich erstaunt darüber, wie machtlos viele Programmierer werden, wenn das Netzwerk erst einmal "aufhört".

• Wireshark , um zu sehen, wie Ihr Code Paket für Paket in einer Blackbox ausgeführt wird
• Tools zum direkten Herstellen einer Verbindung zu Netzwerkdiensten:
  • Telnet, Netcat oder Socat für einfache Verbindungen über TCP oder UDP
  • OpenSSL für die gleiche Sache mit Verschlüsselung (Hinweis: versuchen Sie es openssl s_client -connect target-host:porteinmal), um manuell eine Verbindung zu Netzwerkdiensten herzustellen
• dig (im BIND 9-Paket) zum Debuggen der Namensauflösung
• Ermitteln, welcher Teil des Netzwerkstapels aufgrund des Timings und anderer Merkmale einer fehlgeschlagenen Verbindung fehlgeschlagen ist
• Möglicherweise HTTPFox und / oder Firebug

Wissen, wie Probleme behoben werden.

Es ist sehr einfach, den Geldbeutel zu überholen (z. B. wenn Ihr Netzwerk meine Kommunikation mit der Datenbank blockiert). Möglicherweise liegt es am Netzwerk, aber Sie sollten Anwendungsprotokolle mit Fehlern haben, die bei Verwendung von Google oder SO ein Problem in der Konfiguration einer App aufdecken können.

Alle geben gerne der Hardware, dem Betriebssystem oder dem Netzwerk die Schuld. Wenn Sie also ein wenig mehr Sorgfalt walten lassen, werden Sie den Sysadmin zu einer glücklichen Person machen. Denn wenn nichts anderes möglich ist, können Sie sie möglicherweise in eine bestimmte Richtung lenken, um festzustellen, was möglicherweise nicht stimmt (im Gegensatz zu "Ihr Netzwerk ist scheiße" oder etwas ähnlich Nützlichem).

Dokumentieren Sie alles, was Sie können. Ich kann Ihnen nicht sagen, wie oft der letzte Systemadministrator gedacht hat, es wäre niedlich, etwas für die „Arbeitsplatzsicherheit“ nicht zu dokumentieren, oder jemand wollte einfach nur ein- und aussteigen. So wie ein Programmierer gute Kommentare hinterlassen sollte, sollten Sysadmins dies dokumentieren. Ein Diagramm der Topologie wäre auch schön.

Plan B.

Denken Sie beim Entwerfen und Entwickeln einer Lösung immer an einen Notfallwiederherstellungsplan. Erkennen Sie einzelne Fehlerstellen, die zu einem Ausfall führen können.

Dokumentation: Keine Nüsse, aber wie die Anwendung funktioniert. Ein Diagramm zeigt, wie die Bits passen und wie jede Komponente getestet werden kann, wenn alles schief geht. Beispieldaten und Ausgabe sind nett.

Anforderungen: Auf welchen Modulen basiert es? Versionen? OS?

Überwachung: Im Idealfall fügen Entwickler der Anwendung Überwachungsinformationen und -tests hinzu.

Apropos Verpackung, VERPACKUNG! Nichts schlimmeres als eine "Bereitstellung", bei der eine neue Revision einer Datei von VCS ausgecheckt und auf eine Reihe von Servern kopiert wird. Zu oft schätzen Programmierer die Komplexität der Softwarebereitstellung nicht: Es gibt Gründe, warum versionierte, gepackte Software das Rückgrat der meisten Betriebssysteme bildet.

Wenn ein Entwickler mit einem RPM zu mir käme, das zum ersten Mal mit einer übersichtlichen, umfassenden Dokumentation und einigen Nagios-Tests installiert wurde, wäre er mein neuer bester Freund.

Ich bin überrascht, dass keine der 17 Antworten, die hier bisher gegeben wurden, Hinweise zur Sicherstellung der Ausführung Ihrer Anwendung enthält, wenn Sie als Standardbenutzer angemeldet sind.

Abgesehen vom Installationsvorgang sollte die Anwendung ordnungsgemäß ausgeführt werden, wenn Sie mit einem Standardbenutzerkonto angemeldet ist.

Backup Backup Backup .... Testen Sie das Backup .... Seien Sie immer bereit, ein Rollback durchzuführen

Dies gilt möglicherweise nur für Anfänger, aber ich beschäftige mich mit einigen Programmierern bei jedem Projekt mit ein paar Dingen.

1. "Es funktioniert auf meinem Computer" ist keine gültige Aussage. Es liegt in der Verantwortung des Programmierers, ein Installationsprogramm zur Verwendung auf dem Server zu erstellen oder zumindest alle Verbindungen und DLLs und Add-Ins zu dokumentieren, die auf dem Server erforderlich sind.

2. (Ich habe das schon mehrere Male gehört, also bitte nicht lachen.) Ich starte die Exe auf dem Server von meinem Computer aus und es funktioniert. Wenn ich es jedoch auf dem Server (Citrix, Terminal Server usw.) ausführe, funktioniert es nicht. Bitte verstehen Sie die DLLs und OCXs und alles andere, was Ihr Programm benötigt und wo und wie sie registriert sind und wie Ihr Programm sie verwendet.

Diese mögen einfach erscheinen, aber ich beschäftige mich ständig damit.

Brian

• Sprechen Sie mit Ihrem Administrator formell und informell darüber, was Sie tun. Sie sind in der Regel interessiert und können mögliche Auswirkungen auf die Produktion frühzeitig ausdrücken. Sie müssen nicht zustimmen, aber es hilft, Problemstellen zu identifizieren.
• Nein, Sie können nicht den gesamten Server für sich alleine haben ... Wenn Sie müssen, ist es eine politische Entscheidung, unabhängig davon, wie technisch solide sie ist. Wenn Sie die Politik betreiben wollen, fahren Sie fort.
• Produktionshardware sieht oft anders aus als Ihr Entwicklungsserver, und selbst innerhalb von Farmen sind die technischen Daten auf Computern unterschiedlich.
• Erfahren Sie, wie die Produktion eingerichtet wird, da Sie sie wahrscheinlich nicht auf Ihrem Desktop replizieren können. Auf diese Weise können Sie keine schlechten Annahmen treffen.
• Nur weil Sie Sachen im Speicher zwischenspeichern können, heißt das nicht, dass Sie es sollten. Warten Sie zuerst auf den Engpass (beim Unit-Test oder beim Pre-Production-Performance-Test).
• Wenn Sie Daten in einer Datenbank speichern, überlegen Sie, wie Sie die Daten in schreibgeschützte Daten (die horizontal skaliert werden können) und schreibgeschützte Daten (die normalerweise nur vertikal skaliert werden) aufteilen können.
• Wenn Sie Daten in eine Datenbank stecken, muss das wirklich ein RDBMS sein? Es gibt andere Schlüssel-Wert-Paar-Systeme, die sich besser skalieren lassen (Netcache).
• Denken Sie nicht, dass AJAX die Komplettlösung ist, es sieht cool aus, schränkt aber die Überwachungs- und Automatisierungsmöglichkeiten ein. Ich sage nicht, benutze es nicht, denke nur zweimal darüber nach.

OK, das ist etwas scherzhaft, aber:

a) Gehen Sie beim Codieren davon aus, dass die zugrunde liegende Infrastruktur ausfallen könnte und nicht von einem Land stammt, das immer glücklich ist. Oder Google.

b) Wir haben wahrscheinlich nicht die Ressourcen, um so etwas wie die Infrastruktur zu implementieren, über die Sie gelesen haben. Machen Sie es uns leicht, wenn die Dinge schief gehen. Es ist wahrscheinlich, dass wir wissen, was zu tun ist, aber aus welchem ​​Grund auch immer, es ist noch nicht geschehen. Wir sind Ihre Partner!

c) Wie oben bereits erwähnt, wäre es sehr hilfreich, wenn Sie mit Tools zur Fehlerbehebung vertraut wären, z. B. Ping, Traceroute (oder die Kombination von beidem), Dig usw. Riesige Bonuspunkte, um überhaupt etwas über Wireshark zu wissen.

d) Wenn Sie einen Computer programmieren, sollten Sie wirklich wissen, wie er sich mit dem Netzwerk verbindet, und die Grundlagen wie die Möglichkeit, die Ausgabe von ipconfig / all oder ifconfig zu analysieren. Sie sollten in der Lage sein, Ihre Internetverbindung mit minimaler Hilfe zum Laufen zu bringen.

Ansonsten denke ich, dass Avery es ziemlich genau hinbekommen hat. Entwickler, die ein bisschen Systemadministration betreiben, sind Gold wert! Aber auch Sysadmins, die verstehen, wie Entwickler vorgehen (einschließlich Versionsverwaltung usw.), sind heutzutage ziemlich wichtig.

Dies scheint im Moment in der Luft zu sein, ich habe mehr Diskussionen über die Beziehung zwischen Entwicklern und Betreibern in Blogs bemerkt - check out

Twitter weiterzwitschern

Trennwände und Kriegsführung

Erster Test im Betrieb

Dass keine Gruppe oder Funktion „besser“ ist als die andere und dass auch keine „größere Gehirne“ benötigt als die anderen. Ich habe gesehen, dass beide Seiten im Unternehmen des anderen überaus wichtig sind - Sie alle versuchen, die gleichen Ziele zu erreichen -, konzentrieren Sie sich auf diese Gemeinsamkeiten und nicht auf die Tatsache, dass Sie unterschiedliche Tools verwenden.

Der Infrastrukturarchitekt wurde zum Programmierer und möchte diese Transaktion möglicherweise in Zukunft zurücksetzen :)

1. Sprechen Sie früh und oft miteinander. Überprüfen Sie die Entwürfe mit den Mitarbeitern, die die Infrastruktur verwalten, auf der Ihre App bereitgestellt wird (wenn Sie wissen, wer das sein wird).
2. Es ist möglich, dass keine Daten verloren gehen. Entwickler und Systemadministratoren tragen jedoch die Verantwortung dafür. Auch hier kann es hilfreich sein, miteinander zu reden.
3. Ihr Infrastrukturpersonal sollte in die Ermittlung der nicht funktionalen Anforderungen einbezogen worden sein.
4. Arrangiere Bier (wenn die Arbeit erledigt ist) und Pizza (während wir arbeiten). Irgendwie beeinflusst das Vorhandensein dieser Art von Essen unsere Fähigkeit, unsere netten kleinen 32-CPU-Boxen dazu zu bringen, das zu tun, was Sie wollen :)

Als jemand, der ein Sys-Administrator für Entwickler war, und als Entwickler selbst, ist der Ratschlag, der hier gegeben wird, nicht nur Gold, sondern sollte Teil der Einstellungsdokumentation für neue Entwickler für Unternehmen auf der ganzen Welt sein.

Was ich (noch) nicht gesehen habe, ist, dass Entwickler wirklich die Produkte kennen sollten, mit denen sie die Programme erstellen, für die sie bezahlt werden. Die Häufigkeit, mit der ich Apache-Server, Eclipse- und Visual Studio-Installationen sowie Datenbanken auf Entwicklermaschinen erklären und konfigurieren musste, ist ein wenig besorgniserregend.