- PagerDuty /
- Der Blog /
- Alarmierung /
- 10 häufige Fehler im Betrieb
Der Blog
10 häufige Fehler im Betrieb
Aktualisiert am 24.07.2014: Dieser Blogbeitrag wurde aktualisiert, um Arups Vortrag genauer wiederzugeben.
Arup Chakrabarti, Betriebsingenieur bei PagerDuty, kam in die Zentrale von Heavybit Industries, um die größten Fehler zu besprechen, die ein Betriebsteam machen kann, und wie man sie vermeiden kann. Das vollständige Video finden Sie unter Heavybits-Videobibliothek .
1. Fehler beim Einrichten der Infrastruktur
Konten erstellen
Viele Benutzer verwenden beim Einrichten von Unternehmensinfrastrukturbereitstellungen persönliche Konten. Erstellen Sie stattdessen neue Konten mit Unternehmensadressen, um Konsistenz zu gewährleisten.
Seien Sie vorsichtig, wie Sie Passwörter speichern. Wenn Sie sie in Ihrem Git-Repository aufbewahren, müssen Sie möglicherweise später Ihren gesamten Git-Verlauf löschen. Es ist besser, Passwörter im Konfigurationsmanagement zu speichern, damit sie bei Bedarf eingefügt werden können.
Werkzeuge auswählen
Ein weiterer guter Schritt bei neuen Bereitstellungen: Wählen Sie Ihre Tools mit Bedacht aus. Nutzen Sie beispielsweise PaaS-Tools so lange wie möglich – auf diese Weise können Sie sich auf die Kundengewinnung konzentrieren, anstatt die Infrastruktur aufzubauen. Und scheuen Sie sich nicht, „langweilige“ Produkte wie Java einzusetzen. Mit bewährter, bewährter Technologie können Sie wirklich coole Sachen machen.
2. Schlecht konzipierte Testumgebungen
Halten Sie Test und Produktion getrennt
Sie möchten nicht riskieren, dass sich Ihre Test- und Produktionsumgebungen in irgendeiner Weise vermischen. Richten Sie Testumgebungen unbedingt mit anderen Hosting- und Providerkonten ein als die, die Sie in der Produktion verwenden.
Virtuelle Maschinen
Sie führen lokale Entwicklung durch? Daran führt kein Weg vorbei: Anwendungen laufen auf lokalen Rechnern anders als in der Produktion. Um eine Produktionsumgebung so genau wie möglich zu simulieren, erstellen Sie VMs mit einem Tool wie Vagrant.
3. Falsches Konfigurationsmanagement
Sowohl Ansible als auch Salt sind Tools, die wirklich leicht zu erlernen sind. Insbesondere Ansible macht die Bereitstellung von Infrastruktur als Code für Betriebsteams supereinfach.
Was ist Infrastruktur als Code? Im Wesentlichen handelt es sich dabei um den Prozess, eine Infrastruktur so aufzubauen, dass sie schnell und konsistent hoch- oder heruntergefahren werden kann. Serverkonfigurationen werden immer durcheinander geraten, egal wo Ihre Infrastruktur läuft. Sie müssen also darauf vorbereitet sein, Ihre Server so schnell wie möglich wiederherzustellen.
Unabhängig davon, welches Tool Sie verwenden, gilt als Faustregel: Beschränken Sie die Anzahl der Automatisierungssoftwaretools, die Sie verwenden. Jedes einzelne ist eine Quelle der Wahrheit in Ihrer Infrastruktur, was bedeutet, dass es auch eine Fehlerquelle darstellt.
4. Falsche Bereitstellung
Konsistenz ist wichtig
Jeder Codeabschnitt muss so ähnlich wie möglich bereitgestellt werden. Es kann jedoch eine Herausforderung sein, alle Ihre Entwickler dazu zu bringen, Konsistenz zu praktizieren.
Koordinieren Sie Ihre Bemühungen
Leistungsstarke Automatisierungssoftware kann sicherlich dabei helfen, Konsistenz durchzusetzen. Automatisierungstools sind jedoch nur für große Bereitstellungen geeignet. Arup empfiehlt daher, die Entwicklung zu Beginn mit Git durchzuführen und ein Orchestrierungstool zu verwenden. Beispielsweise Capistrano für Rails, Celery für Python oder Ansible und Salt für Orchestrierung und Konfigurationsmanagement.
5. Vorfälle nicht richtig handhaben
Sorgen Sie für einen etablierten Prozess
Das Erstellen und Dokumentieren eines Vorfallmanagementprozesses ist unbedingt erforderlich, auch wenn der Prozess nicht perfekt ist.
Sie sollten auch darauf vorbereitet sein, das Vorfallmanagementdokument regelmäßig zu überprüfen. Wenn Sie viele Ausfallzeiten haben, sind Überprüfungen nicht wirklich notwendig.
Alle auf Abruf bereithalten
In Unternehmen wird es immer seltener, über dedizierte Bereitschaftsteams zu verfügen. Stattdessen wird von jedem, der mit Produktionscode in Berührung kommt, erwartet, dass er im Falle von Ausfallzeiten erreichbar ist.
Dies erfordert eine Plattform (wie PagerDuty), die verschiedene Personen auf unterschiedliche Weise benachrichtigen kann. Was wirklich zählt, ist, die richtigen Personen zur richtigen Zeit zu erreichen.
6. Vernachlässigung von Überwachung und Alarmierung
Beginnen Sie überall
Das spezifische Tool, das Sie zur Überwachung verwenden, ist weniger wichtig als die bloße Implementierung. PagerDuty verwendet StatsD in Verbindung mit Datadog; Open-Source-Tools wie Nagios können genauso effektiv sein.
Wenn Sie das Geld haben, könnte ein Tool zur Anwendungsleistungsverwaltung wie New Relic eine gute Lösung sein. Am wichtigsten ist jedoch, dass Sie ein Überwachungstool zur Hand haben.
„Sie haben keine Entschuldigung dafür, Ihre App nicht zu überwachen und keine Warnmeldungen zu haben, nicht einmal beim ersten Start“, – Arup Chakrabarti, Engineering Manager, PagerDuty
7. Keine Backups durchführen
Systematisierung von Backups und Wiederherstellungen
Genau wie Überwachung und Warnmeldungen ist die Sicherung Ihrer Daten unverzichtbar. Die Planung regelmäßiger Sicherungen in S3 ist heute eine gängige Branchenpraxis.
Sie sollten mindestens einmal im Monat versuchen, Ihren Produktionsdatensatz in einer Testumgebung wiederherzustellen, um zu bestätigen, dass Ihre Sicherungen wie vorgesehen funktionieren.
8. Ignorieren von Hochverfügbarkeitsprinzipien
Das Schlagwort lautet „Multiple“
Mehrere Server auf jeder Ebene, mehrere Stateless-App-Server und mehrere Load Balancer sind ein Kinderspiel. Nur mit mehreren Failover-Optionen können Sie wirklich sagen, dass Sie für HA optimiert haben.
Auch das Datastore-Design ist wichtig
Datenspeicher (wie Cassandra) sind unerlässlich, da bei Multimaster-Datenclustern einzelne Knoten ohne jegliche Beeinträchtigung des Kunden entfernt werden können. Aus diesem Grund sind Cluster-Datenspeicher ideal für schnelllebige Bereitstellungsumgebungen.
9. In gängige Sicherheitsfallen tappen
Ausschließlich auf SSH angewiesen
Verwenden Sie Gateway-Boxen statt SSH auf Ihren Datenbankservern und Lastverteilern. Sie können Proxys über diese Gateways ausführen und den Datenverkehr sperren, wenn Sie einen Eindringling vermuten.
Keine individuellen Benutzerkonten konfigurieren
Wenn ein Mitarbeiter Ihr Unternehmen verlässt, ist es schön, seinen Zugriff schnell widerrufen zu können. Aber es gibt noch andere Gründe, Benutzern Benutzerkonten für Ihre verschiedenen Tools zuzuweisen. Jemandes Laptop könnte verloren gehen. Jemand muss vielleicht sein Passwort zurücksetzen. Arup merkt an, dass es viel einfacher ist, ein Benutzerpasswort zu widerrufen oder zurückzusetzen als ein Hauptkontopasswort.
Die Aktivierung der Verschlüsselung in dev schlägt fehl
Wenn Sie die Verschlüsselung in den Entwicklungszyklus integrieren, können Sie sicherheitsrelevante Fehler frühzeitig erkennen. Außerdem ist es einfach eine gute Praxis, Entwickler dazu zu zwingen, ständig über Sicherheit nachzudenken.
10. Ignorieren interner IT-Anforderungen
Nicht unbedingt ein Betriebsproblem, aber …
Die IT ist nicht immer das Anliegen des Betriebs. Aber bei bestimmten Themen sind beide Teams beteiligt. Zum Beispiel:
-
Gemeinsamkeiten bei der Ausstattung : Wenn eine Ingenieurin ihren selbstgebauten Laptop verliert, wie lange dauert es, bis sie Ersatz bekommt? Streben Sie Konsistenz bei der Hardware an, um die Bereitstellung der Maschinen zu optimieren.
-
Zugriff auf die richtigen Tools gewähren : Onboarding-Dokumente sind eine gute Möglichkeit, neuen Mitarbeitern Anmeldeinformationen mitzuteilen.
-
Imaging lokaler Rechner : Mit auf USB gespeicherten Disk-Images ist die Bereitstellung oder Neubereitstellung von Geräten ein Kinderspiel.
-
Festplattenverschlüsselung aktivieren : Dank Verschlüsselung besteht kein Grund zur Sorge, wenn ein Computer verloren geht.
Es gibt noch Millionen weiterer Fehler, die Betriebsteams machen können. Diese 10 Fehler sind jedoch die am häufigsten vorkommenden, selbst bei Unternehmen wie Amazon, Netflix und PagerDuty.
Haben Sie Ihren eigenen Ops-Fehler, den Sie gerne mit uns teilen möchten? Lassen Sie es uns in den Kommentaren unten wissen.