Ihr Hoster sollte das Ticket zuerst eröffnen.
Auf unserem Desk eröffnen wir viele Tickets selbst, aus unserem eigenen Monitoring, bevor der Kunde irgendetwas meldet. Hier ist das Betriebsmodell dahinter: namentlich bekannte Ingenieure, die in der Infrastruktur stehen, keine Warteschlange, die an ihrem Rand wartet.
In diesem Artikel 3 Abschnitte
- Auf unserem Desk eröffnen wir viele Tickets selbst, aus unserem eigenen Monitoring und unserer Sicherheitserkennung, bevor der Kunde irgendetwas meldet.
- Das Modell hat vier Züge: Wir eröffnen das Ticket, ein namentlich bekannter Ingenieur verantwortet es von Anfang bis Ende, wir betten unsere Werkzeuge in Ihren Betrieb ein, und die größte Arbeit läuft als Projekt, außerhalb des Tickets.
- Die Grenze ist sauber: Sie betreiben Ihr Geschäft und Ihre Anwendung. Wir betreiben, und bauen, alles darunter.
- Nichts davon ist eine Stufe oder ein Zusatz. So arbeitet der Desk.
Beginnen Sie mit der Benachrichtigung, die Sie nicht geschickt haben. Ein Ticket, bereits eröffnet, bereits mit Verantwortlichem, und die erste Nachricht darin ist von uns. Wenn Sie bisher nur Hosting-Support kannten, der am anderen Ende einer Warteschlange wartet, ergibt diese Erfahrung beim ersten Mal keinen Sinn.
Viele unserer Tickets beginnen so, weil das Betriebsmodell darauf gebaut ist, zuerst zu handeln.
Die vier Züge eines vorgeschobenen Teams
Wir eröffnen das Ticket zuerst
Monitoring und Sicherheitserkennung sind mit Handeln verdrahtet, sodass die erste Nachricht in einem Ticket oft unsere ist.
Ein namentlich bekannter Mensch verantwortet es, von Anfang bis Ende, ohne Stufen
Dieselben Ingenieure, die die Server ins Rack bauen, antworten im Kanal. Keine L1-Mauer, keine Übergaben zwischen Stufen. Die Beziehung besteht zu einer Person, nicht zu einer Warteschlange.
Wir betten unsere Werkzeuge in Ihren Betrieb ein
Das klarste Erkennungszeichen des Modells: Wir haben für Kunden Self-Service-Bedienoberflächen über Infrastruktur gebaut, die wir betreiben, sodass ihre Mitarbeiter den Alltag steuern, während wir die Infrastruktur darunter verantworten. Die ganze Geschichte dieses Builds steht in Wir haben ein VPN Control Center für das eigene Team einer Agentur gebaut.
Die größte Arbeit läuft als Projekt, außerhalb des Tickets
Wenn ein Auftrag über die Warteschlange hinauswächst (eine Plattformmigration, eine Neuarchitektur), wird er zu einer Bestandsaufnahme, einer Freigabe und einem Cutover-Playbook. Das ist Eine Migration ist ein Projekt, kein Ticket.
“Im Alltag sieht es aus, als hätten Sie ein Infrastrukturteam im Haus, dem zufällig auch die Hardware und das Netzwerk gehören, auf denen es läuft.”
Wer macht was
Die Grenze lohnt sich genau zu benennen. Unseres ist das Blech und alles unter der Anwendung: Provisionierung, Migrationen und ihre Cutovers, Architektur für sicheren Zugang, Staging und Pre-Production, die Observability-Pipeline, das SAN und die Netzwerk-Fabric, die Backup- und DR-Aufstellung, Performance- und Security-Engineering. Wir übernehmen die Verantwortung für die Schicht, nicht nur für das Ticket. Ihres ist die Anwendung und die Geschäftslogik: was ausgeliefert wird und wann, ihr Code, ihr Datenmodell, ihre Release-Entscheidung. Wir sitzen beim Deploy dabei. Es bleibt ihr Deploy.
| SIE BETREIBEN | WIR BETREIBEN, UND BAUEN |
|---|---|
| Ihre Anwendung und ihren Code | Alles darunter: Compute, SAN, Netzwerk-Fabric |
| Ihr Datenmodell und Ihre Geschäftslogik | Die Datenbankplattform, ihre Backups, ihre DR-Aufstellung |
| Die Release-Entscheidung: was ausgeliefert wird, und wann | Die Staging-Ebene, das Deploy, das Cutover-Playbook |
| WO ES VERSCHWIMMT, MIT ABSICHTDen Alltagsbetrieb Ihres Teams | Die Bedienoberflächen, mit denen Ihr Team arbeitet |
Die Grenze verschwimmt an einer Stelle, mit Absicht: Wir bauen zunehmend die Werkzeuge, mit denen Ihr Team sich am Rand unserer Schicht selbst bedienen kann, sodass Ihre Leute souverän auf Infrastruktur arbeiten, die sie nicht verstehen müssen. Wir geben kein Runbook zurück und gehen. Wir geben eine Bedienoberfläche zurück und bleiben.
Wer es so kauft
Medien- und Verlagsplattformen dominieren, weil Release-Geschwindigkeit und Traffic-Spitzen für sie existenziell sind. Digitalagenturen, die ihre eigenen Endkunden bedienen, folgen dicht dahinter, weil sie es sich nicht leisten können, vor einem Kunden klein auszusehen. Unternehmen mit mehreren Rechenzentren sind auch dabei. Die Emotion des Käufers unterscheidet sich, aber die Bitte ist jedes Mal dieselbe: Seien Sie unser Engineering-Team, nicht unser Helpdesk.
Reaktionszeiten sind auf unserer Support-Seite veröffentlicht. In diesem Beitrag geht es darum, wer zuerst handelt und wer die Arbeit verantwortet.
Klare Antworten
Was bedeutet proaktives Server-Monitoring tatsächlich?+
Dass Erkennung auf Anbieterseite mit Handeln verdrahtet ist. Auf unserem Desk eröffnen wir viele Tickets selbst, aus Monitoring und Sicherheitserkennung, bevor der Kunde irgendetwas meldet.
Bekomme ich beim Managed Hosting einen festen Ingenieur?+
Hier verantwortet ein namentlich bekannter Ingenieur das Anliegen von Anfang bis Ende, und dasselbe Team, das die Hardware ins Rack baut, antwortet im Kanal. Es gibt kein Stufensystem. Das Modell ist eine Person, keine Warteschlange.
Was passiert, wenn um 3 Uhr morgens etwas kaputtgeht?+
Das Monitoring ist so verdrahtet, dass es das Ticket eröffnet, also ist um 3 Uhr morgens die erste Nachricht meist unsere. Reaktionszeiten stehen auf der Support-Seite. Wenn Ihre Workload eine bestimmte Zusage braucht, legen wir sie gemeinsam mit Ihnen fest.
Kann mein eigenes Team weiterhin selbst Dinge verwalten?+
Ja, mit Absicht. Wir bauen für Kunden Bedienoberflächen über die Infrastruktur, die wir betreiben (Benutzerverwaltung, Zugänge, Alltagsbetrieb), sodass Ihr Team steuert und wir die Infrastruktur darunter verantworten.
Was ist der Unterschied zwischen Managed Hosting und einem eigenen Ops-Team?+
Die Grenze. Sie betreiben die Anwendung und das Geschäft, wir betreiben und bauen die Schicht darunter, und die größte Arbeit läuft als Engineering-Projekt statt als Ticket.
Die erste Nachricht sollte unsere sein.
Namentlich bekannte Ingenieure, ohne Stufen, mitten in der Infrastruktur, auf der Ihr Geschäft läuft.
Mit einem Ingenieur sprechenSie haben das Ende erreicht.
Setzen Sie das Gelesene um
Was betreiben Sie?
Erzählen Sie uns von Workload, Traffic und Anforderungen an die Wiederherstellung. Beginnen Sie mit dem Server-Konfigurator oder besprechen Sie die Details mit einem Ingenieur.
Geschrieben von den Ingenieuren, die die beschriebene Infrastruktur bauen und betreiben.Mit einem Ingenieur sprechen