In jeder Flotte, die länger als ein Jahr existiert, laufen mehr Firmware-Versionen, als der Betreiber annimmt. Die Kluft zwischen Beabsichtigtem und Tatsächlichem ist eine Abweichung und erschwert in aller Stille die Diagnose aller anderen Dinge.
Der Grund dafür ist nicht, dass alte Firmware schlechter ist. Der Grund dafür ist, dass das gleiche Symptom bei unterschiedlichen Builds unterschiedliche Ursachen hat, was Fehlermuster unleserlich macht.
Wie Drift entsteht
Nichts davon ist isoliert betrachtet ein Fehler. Gemeinsam erschaffen sie eine Flotte, deren Versionsverteilung niemand wählte.
- Einheiten, die während eines Rollouts offline waren, die Nachricht nie erhalten haben und nie erneut versucht wurden.
- Garantie-Ersatzteile werden ab Lager für die damals aktuelle Version geliefert.
- Einheiten, die aus Lagerbeständen in Auftrag gegeben wurden, die monatelang stillgelegt waren.
- Die Rollouts wurden nach einem Problem teilweise unterbrochen und nie wieder aufgenommen.
- Außendiensttechniker, die Geräte neu flashen, um ein Problem zu lösen, und dabei das ihnen zur Verfügung stehende Bild verwenden.
Warum es die Diagnose zerstört
Die Fehleranalyse basiert auf der Gruppierung ähnlicher Ereignisse. Wenn ein Symptom bei einem Build eine Ursache und bei einem anderen eine andere Ursache hat, führt die Gruppierung nach Symptom zu einer Mischung und das Muster verschwindet.
Die Teams kommen dann zu dem Schluss, dass der Fehler zufällig oder umgebungsbedingt ist, wenn beides nicht der Fall ist. Es werden zwei Fehler als einer gewertet.
Es unterbricht auch Integrationen
Protokollverhalten, Konfigurationsschlüsselunterstützung und Fehlercodezuordnung können sich zwischen den Versionen ändern. Eine für einen Build verifizierte Plattformintegration verhält sich möglicherweise auf einem anderen Build anders, und der Unterschied zeigt sich in zeitweiligen plattformseitigen Fehlern.
Aus diesem Grund sollte eine Integrationsposition die Firmware-Version aufzeichnen, anhand derer sie verifiziert wurde, und nicht nur das Ladegerätmodell.
Messen Sie die tatsächliche Verteilung
Der erste Schritt besteht darin, zu wissen, was bereitgestellt wird, und nicht, was beabsichtigt war. Ladegeräte melden ihre laufende Version, und der Abgleich dieser Version mit der Rollout-Aufzeichnung ist beim ersten Mal meist eine überraschende Aufgabe.
Die Festlegung dieser Verteilung ist häufig das nützlichste Ergebnis einer Netzwerkprüfung.
Konvergieren Sie bewusst
- Versuchen Sie Rollouts gegen Einheiten, die nicht erreichbar waren, erneut, anstatt einen Rollout als abgeschlossen zu betrachten, wenn er gestoppt wird.
- Aktualisieren Sie den Ersatzbestand vor der Bereitstellung oder aktualisieren Sie ihn bei der ersten Verbindung.
- Verhindern Sie das erneute Blinken von Feldern außerhalb des verwalteten Prozesses oder zeichnen Sie es auf, wenn es auftritt.
- Melden Sie die Versionsverteilung routinemäßig, sodass Abweichungen sichtbar sind, auch wenn sie gering sind.
Konvergiert bedeutet nicht „aktuell“.
Das Ziel ist eine kleine Anzahl bekannter Versionen, nicht unbedingt die neuesten. Eine Flotte, die bewusst auf einem validierten Build basiert, ist überschaubar; Eine Flotte, die auf sechs Builds verteilt ist, die niemand ausgewählt hat, ist es nicht, unabhängig davon, wie neu sie sind.
Die Entscheidung, welche Versionen unterstützt werden, und die Einstellung der übrigen Versionen ist die Praxis, die dafür sorgt, dass dies auch dann beherrschbar bleibt, wenn eine Flotte wächst.