Laravel-Entwicklung für Unternehmen in Mannheim

Wenn in Mannheim und Ludwigshafen um drei Uhr nachts eine Anwendung stehen bleibt, wartet niemand bis zum Morgen. Die Region ist einer der dichtesten Industrieräume Deutschlands, mit Chemie, Maschinenbau, Elektrotechnik, Energie und Logistik am Rhein, und ein großer Teil davon arbeitet durchgehend.

Dazu kommt eine ungewöhnlich hohe Dichte an Forschung und Entwicklung. In der Metropolregion arbeiten deutlich mehr Menschen in forschungsnahen Berufen als im Bundesdurchschnitt, was sich in den Anfragen bemerkbar macht: Die Gesprächspartner wissen meistens genau, was sie wollen.

Dauerbetrieb ändert die Prioritäten

Technisch unterscheidet sich eine Anwendung für den Schichtbetrieb kaum von einer anderen. Was sich unterscheidet, ist die Bewertung von Fehlern. Eine Störung, die anderswo ein Ärgernis wäre, hält hier eine Schicht auf, und die Kosten dafür stehen in keinem Verhältnis zum Entwicklungsaufwand, den man gespart hat.

Deshalb legen wir in solchen Projekten mehr Gewicht auf die unspektakulären Dinge. Was tut die Anwendung, wenn ein Nachbarsystem nicht antwortet? Wird ein abgebrochener Vorgang sauber zurückgerollt oder bleibt er halb erledigt liegen? Kann jemand ohne uns erkennen, was schiefging?

Diese Fragen kosten beim Bauen wenig und entscheiden im Betrieb alles. Wie wir dabei vorgehen, steht unter Laravel-Entwicklung.

Aktualisieren, ohne anzuhalten

Die zweite Eigenheit betrifft Wartung. Wo es keinen ruhigen Moment gibt, muss eine Aktualisierung im Betrieb möglich sein. Machbar ist das, es verlangt nur Vorarbeit. Änderungen an der Datenbank kommen in kleinen Schritten, alte und neue Fassung laufen eine Weile nebeneinander, und die Schnittstellen müssen beides vertragen.

Wer das erst später einbaut, zahlt doppelt. Wie wir laufende Anwendungen betreuen, steht unter Wartung und Support.

Der Notbetrieb gehört in den Entwurf

Eine Anwendung, die im Schichtbetrieb läuft, wird irgendwann nicht erreichbar sein. Netzstörung, Stromausfall im falschen Gebäudeteil, ein Nachbarsystem, das eine Wartung länger braucht als geplant.

Die Frage ist nicht, ob das passiert, sondern was die Leute in der Halle dann tun. Meistens ist die Antwort schlicht: Sie schreiben mit und erfassen später nach. Damit das funktioniert, muss die Anwendung eine Nacherfassung zulassen und erkennbar halten, dass ein Wert nachträglich eingetragen wurde. Nachgerüstet wird so etwas selten, weil in dem Moment andere Dinge drängen.

Wer im Störungsfall angerufen wird

In einem Umfeld, das durchgehend arbeitet, ist die Zuständigkeit im Störungsfall keine Formalie. Zwischen Anlagensteuerung, Netz, Datenbank und Anwendung liegen oft vier Verantwortliche, und im Zweifel zeigt jeder auf den nächsten.

Wir legen deshalb vorher fest, woran man erkennt, dass das Problem bei uns liegt, und woran nicht. Dazu gehört, dass unsere Anwendung im Fehlerfall etwas Brauchbares in ihr Protokoll schreibt, statt nur abzubrechen. Das kostet beim Bauen fast nichts und entscheidet nachts um drei darüber, ob jemand in zehn Minuten oder in zwei Stunden weiterkommt. Wie wir solche Vereinbarungen fassen, steht unter Wartung und Support.