Wir alle lieben es, über unsere Erfolge zu sprechen und sprechen nicht wirklich gern über Misserfolge. Die Erfahrung von Fehlern ist jedoch oft wertvoller als der Gewinn aus einem erfolgreich abgeschlossenen Geschäft. Deshalb möchte ich heute nur über solche Fälle sprechen. Also lass uns gehen ...
Topf, nicht kochen!
Diese Geschichte ereignete sich vor einigen Jahren, ganz am Anfang meiner Karriere als 1C-Entwickler.
In unserem Unternehmen ist ein Projekt erschienen, um den Betrieb einer sehr stark belasteten Basis eines sehr großen und angesehenen Kunden zu optimieren. Der Client war mit einem so paranoiden Sicherheitsdienst ausgestattet, dass es keinen Remotezugriff auf die Server von außen gab und gab. Um eine direkte Verbindung zu den Basen zu unserem Büro herzustellen, wurde ein separates lokales Netzwerk mit Hardware-VPN installiert und Workstations mit streng ausgehandelter Software wurden installiert. Natürlich ohne die Rechte eines lokalen Administrators.
Wie jedes andere Projekt dieser Art begann es mit der Datenerfassung. Es wurde davon ausgegangen, dass wir zunächst innerhalb eines Monats verschiedene Indikatoren erfassen und dann die Informationsbasis selbst optimieren werden. Wie und wie viel Zeit in diesem bürokratischen Umfeld für die Einrichtung des Kundencenters benötigt wurde, ist Material für eine separate Geschichte. Aber jetzt, irgendwann, wurde das Kundencenter konfiguriert und gestartet. Danach stieg der Experte, der dieses Projekt durchgeführt hatte (Dima, hi!), In sein luxuriöses Auto und reiste durch unser riesiges Land und dann weiter in die Nachbarländer. Tatsächlich wusste ich immer noch wenig und wusste wie, aber ich wurde bereits als verantwortungsbewusster Entwickler angesehen. Daher wies mich Dmitry vor meiner Abreise eine sehr wichtige und ernste Aufgabe an: 2 Mal am Tag musste ich zum Zeitpunkt der Spitzenlast zu diesem sehr geheimen Computer gehen, Messungen im Kundencenter starten und sie nach einer Stunde ausschalten. Die Anweisungen waren äußerst einfach und klar:
- Sieh mal, du drückst diese kleine grüne Taste "Wiedergabe", verschiedene Charts laufen, wartest eine Stunde, dann drückst du diese Taste - "Stopp". Das ist alles.
Was könnte einfacher sein, oder? Vergebens habe ich 5 Jahre an der Mathematikfakultät studiert?
Die ganze Woche habe ich dieses Ritual morgens und abends genau eingehalten. Und bis zum letzten Tag war alles in Ordnung. Nach dem Mittagessen begann ich wie üblich am Freitag mit dem Sammeln von Daten und dann ... Nun, Sie wissen, wie es passiert ... Freitag, Abend, müssen wir einige dringende Dinge erledigen, einige Aufgaben erledigen, nach der Arbeit meine Frau zu meiner Schwiegermutter bringen in ein Geschäft, ein zweites usw. fallen. Im Allgemeinen habe ich die Arbeit verlassen und dieses unglückliche Kundencenter völlig vergessen.
Der Samstagmorgen begann mit einem Anruf. Wir haben ALLE 1C-te Basis beim Kunden. Achtung und Katastrophe! Unser Experte befindet sich irgendwo zwischen Dzheyrakh und Pasanauri außerhalb des Netzwerkzugangsbereichs. Der Hauptadministrator des Kunden befindet sich ebenfalls in einem Landhaus und ist nicht erreichbar. Was ist der Grund, um am Telefon herauszufinden? Irgendwie stellt sich heraus, dass der Speicherplatz aufgebraucht ist und der 1C-Agentendienst aufgerufen wurde. Hier begann ich schon etwas zu ahnen ...
Wie Sie sich erinnern, gibt es keine Udalenka. Der Computer ist nicht nur vom Internet isoliert, sondern auch außerhalb unseres lokalen Netzwerks. Nichts zu tun - zur Arbeit gehen. Während der Vorbereitung und des Fahrens stellten die Administratoren fest, dass der gesamte Platz von den MCC-Protokollen eingenommen wurde, und taten, was sie für am vernünftigsten hielten - sie schnitten es durch den Task-Manager ab. Mach weiter. Sie können nicht nur Protokolle von der Festplatte löschen - wir verlieren die Messdaten. Irgendwie fanden sie genug Speicherplatz auf der Netzwerkfreigabe und kopierten die Dateien dort. Die Arbeit scheint wieder aufgenommen worden zu sein.
Der Sonntagmorgen begann mit einem Anruf. Wir haben ALLE 1C-te Basis beim Kunden. Achtung und Katastrophe brauchen zwei! Die ganze Panik ist vorbei - der Ort ist vorbei. Aber wie so? MCC ausgeschaltet? In Eile werde ich wieder arbeiten und die Protokolle werfen, um Speicherplatz freizugeben. Und sie alle wachsen und wachsen, verdammt noch mal! Aus Angst vor den perversesten Hinrichtungen verboten mir die Administratoren, irgendetwas zu starten oder überhaupt etwas zu konfigurieren. Den Rest des Sonntags saß ich am Computer und kopierte die Protokolle auf den Ball, damit die Basen nicht wieder aufstanden.
Erst spät in der Nacht meldete sich Dima und sagte, dass Sie nur eine kleine Datei auf dem 1C-Server löschen müssen. Später, ein paar Wochen später, las ich in einem bekannten "Schreibtisch" -Buch über ihn, aber an diesem Tag gingen die Gefolterten erschöpft nach Hause, um zu schlafen.
Am Montagmorgen wurde unser Konto gesperrt, bis Dmitry aus dem Urlaub zurückkehrte, und es wurde ganz klar zu meinem Konto gesagt: "Damit wir ihn nicht wiedersehen!"
So endete mein erstes Optimierungsprojekt für mich.
Zweimal in einem Trichter
Großer Betrieb. 18 Informationsbasen mit identischer Konfiguration im ganzen Land. Das Update findet einmal pro Woche statt und ist das gleiche Ritual: Die Lieferdatei muss im Voraus vorbereitet und in die Cloud hochgeladen werden. Stellen Sie sicher, dass sie in allen Filialen heruntergeladen wurde (selbst im Jahr 2018 ist das Internet in einigen Regionen langsamer als das typische 1C: ERP). Überprüfen Sie, ob überall Backups erstellt wurden (wir scheinen nicht dafür verantwortlich zu sein, aber die bittere Erfahrung hat uns gelehrt, sicher zu sein). Führen Sie dann in jedem Zweig das Aktualisierungsskript manuell aus und stellen Sie sicher, dass es fehlerfrei funktioniert. Oft wird im letzten Moment festgestellt, dass eine weitere Aufgabe in die Lieferung aufgenommen werden muss, und dies ist eine geringfügige Korrektur, da das nächste Update erst in einer Woche erfolgt.
So war es damals. Ein erfahrener Entwickler mit langjähriger Erfahrung in Eile machte einen Fehler in einer Zeile, als er eine Aufgabe auf eine Kampfstrecke übertrug. Der Fehler stellte sich als kritisch heraus und wurde nach dem Aktualisieren aller Datenbanken entdeckt.
Was tun? Der Entwickler repariert den Code schnell. Lässt niemanden testen:
- Ja, es gibt Müll ... Ich kann nicht zweimal in einer Zeile einen Fehler machen?
Eine Stunde später wurden 18 Filialen zum dritten Mal aktualisiert.
Entwickler, der könnte
Die Geschichte eines Kollegen über Skype.
[Kollege]: Es war einmal ein "Entwickler, der konnte!" Er hatte ein Entwicklungsoutfit. Er wollte einen Test eröffnen, verpasste aber und eröffnete einen produktiven ...
[Kollege]: Aber könnte dies den "Entwickler, der könnte" aufhalten? Nein!
[I]: Und als er aktualisiert wurde, verstand er nicht, dass dort sozusagen Leute saßen? )))
[Kollege]: Außerdem sieht er, dass der Konf unterstützt wird ... Aber glauben Sie, dass dies den "Entwickler, der könnte" aufhalten könnte? Nein!
[Kollege]: Er entfernt die Konfiguration vom Support (!) Und sägt seinen Mod unter Umgehung aller Repositories ...
[I]: Das ist es nicht! Beende die Geschichte, dynamisches Update)))
[Kollege]: Updates ... Das System sagt: "Es gibt 18 aktive Sitzungen in der Datenbank!". Aber wie könnte dies den "Entwickler, der könnte" aufhalten? Nein und wieder nein!
[Kollege]: Er aktualisiert die Datenbank und übergibt die Aufgabe an den Test ...
[Kollege]: Der Berater kann das Outfit nicht finden ... und erst dann merkt er nach langer Zeit, dass er es verpasst hat.
[Kollege]: Ich musste ihn schelten ...
[Kollege]: Ich rufe ihn an ... und ich lache ins Telefon ...
[Kollege]: Ich verstehe einfach nicht ... WIE ???
Transportkollaps
Die Geschichte von einem Kollegen erzählt und aus seinen Worten aufgezeichnet.
Es geschah in einem großen Logistikunternehmen. Die meisten Geschäftsprozesse konzentrieren sich auf eine Informationsbasis. Wettbewerbsfähige Nutzer für 2012 - rund 3.000 Menschen aus allen Regionen des Landes.
Stellen Sie eine einfache Aufgabe ein. Demnach hat er ein eigenes Informationsregister erstellt, in das Daten geschrieben werden, wenn bestimmte Dokumente veröffentlicht werden. Obwohl es nicht viele Arten von Dokumenten gibt, ist die Anzahl dieser Dokumente pro Tag enorm. Theoretisch sollte die Schreiboperation, die ich dem Register hinzugefügt habe, das System nicht stark belasten. Bei der Implementierung der Aufgabe gab es jedoch eine Nuance: Beim Aufzeichnen eines Satzes wurde die Eigenschaft Überschreiben auf Falsch gesetzt. Das heißt, jedes Dokument enthält hinzugefügte Einträge im Register. Dies war je nach den Bedingungen des Problems notwendig, hatte aber praktisch keinen Einfluss auf die Leistung, weil Entsprechend den Auswahlbedingungen gab es immer 1-10 Einträge.
Funktionstests waren erfolgreich. Wir haben mehrere Dutzend Dokumente durchgeführt, sichergestellt, dass die Einträge im Register korrekt waren, nichts Verdächtiges bemerkt und sie an das Produktiv gesendet.
An diesem unglücklichen Freitagmorgen haben wir die Kampfbasis aktualisiert und die Benutzer haben begonnen zu arbeiten. 3000 Menschen füllten fröhlich Dokumente und das Register wurde mit Daten gefüllt. Nachdem wir überprüft hatten, ob alles gut lief, gingen wir einige Stunden später mit einer ruhigen Seele nach Hause (wir arbeiten in verschiedenen Zeitzonen mit den Hauptnutzern der Informationsbasis).
Es ist anzumerken, dass die Server, auf denen der IS lief, fast zu den leistungsstärksten in Russland gehören, die unter 1C verwendet wurden. Aber nach ein paar Stunden ist „etwas schief gelaufen“ (c).
Die Benutzer bemerkten einen Rückgang der Systemleistung. Alle Operationen begannen sich zu verlangsamen. Die Reaktionen auf Aktionen wurden länger. Die Belastung der Geräte nahm stetig zu. Während die IT-Abteilung verstand, was vor sich ging, wurde die Arbeit im System fast eingestellt. Die Ausrüstung konnte nicht bewältigen, die Warteschlangen auf den Festplatten waren länger als in den Postämtern Russlands. Wenn die Ausrüstung schwächer wäre, würde das Problem fast sofort erkannt. Aber die mächtigsten Server widerstanden einen halben Tag lang heldenhaft meinen krummen Händen.
"Aus den Worten" von MSSQL wurde die schwerwiegendste Anfrage plötzlich zu einer Leseanforderung in meinem Register. Obwohl ich keine Lesungen gemacht habe. Im 1C-Code wurde schnell ein Problem entdeckt. Ich habe vergessen, eine Auswahl für eine Reihe von Datensätzen festzulegen. Wenn die Eigenschaft "Überschreiben" auf "Wahr" gesetzt würde, würde ich sofort einen Fehler finden, weil Jeder Eintrag würde das gesamte Register löschen. In unserem Fall ist dies jedoch nicht geschehen. Am Beispiel eines Dutzend Dokumente haben wir natürlich keinen Leistungsverlust festgestellt. Aber als sich das Register mit Zehntausenden von Zeilen füllte, musste das System jedes Mal das gesamte Register auf übereinstimmende Datensätze überprüfen.
Zu diesem Zeitpunkt war nach Ansicht einiger Benutzer bereits ein Transportkollaps aufgetreten, weil Autos erhielten keine Dokumente von 1C und konnten die Entladepunkte nicht verlassen.
Also habe ich „nur“ vergessen, eine Auswahl in das Recordset aufzunehmen, und eine der größten 1C-Datenbanken in Russland eingerichtet.
PS Siehe auch: