Votre hébergeur devrait ouvrir le ticket en premier.
Sur notre desk, beaucoup de tickets, c'est nous qui les ouvrons, depuis notre propre supervision, avant que le client ne dépose quoi que ce soit. Voici le modèle opérationnel derrière cela : des ingénieurs nommés qui se tiennent à l'intérieur de l'infrastructure, pas une file qui attend à son extrémité.
Dans cet article 3 sections
- Sur notre desk, beaucoup de tickets, c'est nous qui les ouvrons, depuis notre propre supervision et notre détection de sécurité, avant que le client ne dépose quoi que ce soit.
- Le modèle a quatre gestes : nous ouvrons le ticket, un ingénieur nommé le prend en charge de bout en bout, nous intégrons de l'outillage dans votre exploitation, et le plus gros du travail se fait en projet, hors ticket.
- La frontière est nette : vous faites tourner votre entreprise et votre application. Nous exploitons, et construisons, tout ce qu'il y a en dessous.
- Rien de tout cela n'est un palier ou une option. C'est ainsi que le desk fonctionne.
Commencez par la notification que vous n'avez pas envoyée. Un ticket déjà ouvert, déjà pris en charge, et le premier message dessus vient de nous. Si vous n'avez connu que du support d'hébergement qui attend au bout d'une file, cette expérience n'a aucun sens la première fois qu'elle se produit.
Beaucoup de nos tickets commencent ainsi, parce que le modèle opérationnel est construit pour bouger en premier.
Les quatre gestes d'une équipe déployée en avant
Nous ouvrons le ticket en premier
La supervision et la détection de sécurité sont câblées à l'action, donc le premier message sur un ticket est souvent le nôtre.
Une personne nommée le prend en charge, de bout en bout, sans paliers
Les mêmes ingénieurs qui mettent les serveurs en rack répondent sur le canal. Pas de mur L1, pas de passage de relais entre paliers. La relation est avec une personne, pas avec une file.
Nous intégrons notre outillage dans votre exploitation
Le signe le plus net du modèle : nous avons construit des surfaces de contrôle en self-service pour des clients, sur une infrastructure que nous exploitons, pour que leur personnel pilote au quotidien pendant que nous portons la responsabilité de l'infrastructure en dessous. L'histoire complète de cette construction est dans nous avons construit un VPN Control Center pour l'équipe d'une agence.
Le plus gros du travail se fait en projet, hors ticket
Quand une collaboration dépasse la file (une migration de plateforme, une refonte d'architecture), elle devient un état des lieux, un feu vert et un playbook de bascule. C'est une migration est un projet, pas un ticket.
“Au quotidien, cela ressemble à avoir une équipe infrastructure dans vos effectifs, à qui appartiennent aussi, par hasard, le matériel et le réseau sur lesquels elle tourne.”
Qui fait quoi
La frontière vaut la peine d'être énoncée exactement. À nous le metal et tout ce qui est sous l'application : le provisioning, les migrations et leurs bascules, l'architecture d'accès sécurisé, le staging et la préproduction, le pipeline d'observabilité, le SAN et le fabric réseau, la posture de backup et de DR, l'ingénierie des performances et de la sécurité. Nous prenons la responsabilité de la couche, pas seulement du ticket. À eux l'application et la logique métier : quoi livrer et quand, leur code, leur modèle de données, leur décision de release. Nous restons présents pendant le déploiement. C'est toujours leur déploiement.
| VOUS FAITES TOURNER | NOUS EXPLOITONS, ET CONSTRUISONS |
|---|---|
| Votre application et son code | Tout ce qu'il y a en dessous : calcul, SAN, fabric réseau |
| Votre modèle de données et votre logique métier | La plateforme de bases de données, ses backups, sa posture de DR |
| La décision de release : ce qui sort, et quand | Le tier de staging, le déploiement, le playbook de bascule |
| LÀ OÙ C'EST FLOU, À DESSEINLes opérations quotidiennes de votre équipe | Les surfaces de contrôle avec lesquelles votre équipe opère |
La frontière devient floue à un endroit, délibérément : nous construisons de plus en plus l'outillage qui permet à votre équipe de se servir elle-même à la lisière de notre couche, pour que vos gens opèrent avec assurance sur une infrastructure qu'ils n'ont pas besoin de comprendre. Nous ne rendons pas un runbook avant de partir. Nous rendons une surface de contrôle et nous restons.
Qui l'achète ainsi
Les plateformes de médias et d'éditeurs dominent, parce que la vitesse de release et les pics de trafic sont existentiels pour elles. Les agences digitales qui servent leurs propres clients finaux suivent de près, parce qu'elles ne peuvent pas se permettre de paraître petites devant un client. Les entreprises multi-datacenters sont aussi dans le lot. L'émotion de l'acheteur diffère, mais la demande est la même, à chaque fois : soyez notre équipe d'ingénierie, pas notre help desk.
Les délais de réponse sont publiés sur notre page support. Cet article porte sur qui bouge en premier et qui porte la responsabilité du travail.
Réponses directes
Que signifie réellement la supervision proactive d'un serveur ?+
Que la détection est câblée à l'action du côté du fournisseur. Sur notre desk, beaucoup de tickets, c'est nous qui les ouvrons depuis la supervision et la détection de sécurité, avant que le client ne dépose quoi que ce soit.
Ai-je un ingénieur dédié avec l'hébergement infogéré ?+
Ici, un ingénieur nommé prend le problème en charge de bout en bout, et la même équipe qui met le matériel en rack répond sur le canal. Il n'y a pas de système de paliers. Le modèle est une personne, pas une file.
Que se passe-t-il quand quelque chose casse à 3 heures du matin ?+
La supervision est câblée pour ouvrir le ticket, donc à 3 heures du matin le premier message est en général le nôtre. Les délais de réponse sont sur la page support. Si votre charge a besoin d'un engagement précis, nous le cadrons avec vous.
Ma propre équipe peut-elle encore gérer des choses elle-même ?+
Oui, délibérément. Nous construisons des surfaces de contrôle pour les clients sur l'infrastructure que nous exploitons (gestion des utilisateurs, accès, opérations quotidiennes) pour que votre équipe pilote et que nous portions la responsabilité de l'infrastructure en dessous.
Quelle est la différence entre l'hébergement infogéré et avoir une équipe ops ?+
La frontière. Vous faites tourner l'application et l'entreprise, nous exploitons et construisons la couche en dessous, et le plus gros du travail se fait en projets d'ingénierie plutôt qu'en tickets.
Le premier message devrait être le nôtre.
Des ingénieurs nommés, sans paliers, qui se tiennent à l'intérieur de l'infrastructure sur laquelle tourne votre entreprise.
Parler à un ingénieurVous êtes arrivé à la fin.
Mettez la lecture en pratique
Que faites-vous tourner ?
Parlez-nous de la charge de travail, du trafic et des exigences de reprise. Commencez par le configurateur de serveur, ou passez en revue les détails avec un ingénieur.
Écrit par les ingénieurs qui construisent et exploitent l'infrastructure qu'il décrit.Parler à un ingénieur