Le technicien typique fera face à chaque défi avec une question simple : « Puis-je créer la solution moi-même ? » Et souvent, la question est suffisamment pertinente pour qu'elle soit prise en considération. Alors, faut-il construire ou acheter ? Evaluation d'un solution de gestion des incidents semble désormais poser cette question également. Mais comment savoir quand créer ou acheter votre plateforme de gestion des incidents ?

Pourquoi construire ?

Parfois, le désir de créer votre propre solution est basé sur le simple fait que l'acquisition d'une solution commerciale n'est pas de votre ressort. Par exemple, le service informatique de l'entreprise dispose du budget pour l'outil, mais Équipe DevOps Il peut sembler plus facile de construire une solution à partir de projets open source que de se lancer dans des jeux à long terme pour obtenir une solution achetée. Mais il s'agit d'un problème organisationnel et non technique. Et souvent, la solution construite sur mesure a tendance à être de courte durée.

Mais il existe d’autres raisons pour lesquelles vous pourriez vouloir créer votre propre solution :

• Exigences uniques réelles ou perçues
• Problèmes de sécurité et de confidentialité
• Coût

Ce sont des raisons valables pour envisager de créer votre propre solution de gestion des incidents, mais toutes doivent être examinées attentivement.

Vos besoins sont-ils vraiment uniques ? Pour savoir si c'est le cas, il faut examiner vos concurrents et ce qu'ils utilisent, et comparer vos besoins à ceux d'organisations similaires. Et en même temps, même si vous avez un besoin unique, vous pouvez vous demander pourquoi il est si unique. Est-ce nécessaire qu'il en soit ainsi ?

En ce qui concerne la sécurité , qu'est-ce qu'il y a avec ton sécurité et les problèmes de confidentialité qui les rendent inutilisables pour la gestion des incidents commerciaux ? Est-ce le risque d'exposition des données ? La plupart du temps, les données d'application n'ont pas besoin d'être incluses dans les alertes, mais si elles le sont, c'est un élément à prendre en compte. Si le problème concerne la sécurité en général, gardez à l'esprit que les fournisseurs s'efforcent de s'assurer qu'ils sont au courant des menaces de sécurité. Souvent, ils ont la capacité d'être bien plus au fait des questions de sécurité que les équipes d'exploitation internes.

Et puis il y a le coût. Le coût est un enjeu délicat, car les aspects les plus coûteux de la création de votre propre solution ne sont pas faciles à calculer. Il est facile de calculer les frais mensuels d'un service de gestion des incidents par rapport au coût d'un développement ponctuel effectué par un développeur à temps plein. Cependant, il est difficile d'anticiper la maintenance continue, les changements de fonctionnalités et le plus important : le coût d'opportunité. Sur quoi travailleraient les développeurs s'ils ne créaient pas cette solution ? Et quel est le coût de la mise de côté de projets ou de backlogs pendant le développement ? Un autre problème se pose lorsque la personne qui a créé la solution part en emportant avec elle la compréhension de la base de code. Vous ne voulez pas que des connaissances tribales quittent l'organisation lorsqu'elles sont liées à une partie essentielle de votre infrastructure.

Est-ce que vous vous intégrez ?

La création d'une solution de gestion des incidents présente un point faible particulier : les intégrations. Les plateformes de gestion des incidents performantes ont immense bibliothèque d'intégrations dans les sources (comme votre application et votre infrastructure) et la distribution (comme vos outils de collaboration). La création de ces intégrations prend beaucoup de temps, obligeant souvent les développeurs à apprendre et à créer à partir de nouvelles Apis Les organisations qui créent leur propre plateforme de gestion des incidents n'auront peut-être à travailler qu'avec les intégrations qui les intéressent, car elles n'ont pas besoin de prendre en charge de nombreux cas d'utilisation . Mais lorsque les API de ces systèmes changent, vous pouvez être pris au dépourvu, manquer de nouvelles fonctionnalités ou complètement casser la plateforme. Les projets open source ne vont pas réagir aussi rapidement aux changements d'intégration ou en créer de nouvelles, et si quelque chose se casse, votre développeur, déjà chargé d'autre chose, devrait tout laisser tomber et y remédier. Et bien sûr, le choix des outils avec lesquels votre système de gestion des incidents doit s'intégrer peut également changer en fonction de la situation. l'équipe évolue et ses besoins changent .

Quand construire

Il existe un scénario dans lequel une plateforme de gestion des incidents sur mesure basée sur des projets open source est utile, et c'est dans ce cas qu'elle est nécessaire pour des scénarios très spécifiques et très spécialisés. En général, les organisations qui ont besoin d'une telle solution disposent d'une gestion des incidents commerciale pour l'environnement mondial et la développent ou même l'intègrent dans l'API de la plateforme de gestion des incidents pour le scénario de niche.

L’autre objectif peut être de générer des alertes dans un contexte différent de celui du support d’application ou d’infrastructure. Les alertes peuvent être utilisées pour la collaboration ou la gestion de produits. Dans de tels cas, il peut être utile de segmenter le cas d’utilisation du système de gestion des incidents commerciaux et critiques avec un système plus interne et moins responsable pour les autres cas d’utilisation. Cela peut être vrai pour les équipes qui ont déjà beaucoup de personnalisations lorsqu’il s’agit d’apprendre de l’utilisation de leur application. Par exemple, lorsqu’une nouvelle fonctionnalité est lancée, vous pouvez choisir de recevoir des alertes lorsque cette fonctionnalité est utilisée, ou lorsqu’une nouvelle infrastructure est déployée, vous pouvez choisir d’être alerté lorsque vous atteignez un certain KPI de performance pour comprendre l’impact des changements.

L'autre raison est la fuite de données, à la fois interne et externe. Par exemple, les alertes où la correction expose des informations personnelles identifiables au support interne de niveau 1, mais qu'ils n'ont pas l'autorité de voir. Cela peut être un problème, en particulier dans les secteurs réglementés. Neuf fois sur dix, vous pouvez modifier vos rôles dans la plateforme et ce qui est exposé, donc ce n'est jamais un problème. En général, vous devriez toujours essayer de le faire. Mais il y a des cas rares où cela est inévitable.

Votre heure de gloire

Un technicien expérimenté saura quand il est temps de construire ou d'acheter, au-delà de son intérêt à bricoler et à résoudre des problèmes. La création initiale de la solution n'est pas le point où vous vous retrouvez bloqué. C'est le support à long terme et les risques associés aux solutions personnalisées. Et il ne s'agit pas seulement de la création de la solution : vous devez également l'exécuter. Installez-vous un système de gestion des incidents pour votre système de gestion des incidents ? Devoir se soucier de la disponibilité d'un autre élément est stressant, et si la gestion des incidents tombe en panne, vous volez à l'aveugle.

Les intégrations de niche personnalisées dans votre base de code et votre infrastructure justifient parfois la création de votre propre solution de gestion des incidents. Ou si vous avez des cas d'utilisation non critiques qui sont secondaires à votre gestion des incidents commerciaux, il peut être intéressant de créer la vôtre. En général, cependant, une solution commerciale aura un coût total de possession inférieur, répondra à vos besoins à mesure que vous évoluerez, garantira que les outils et les processus ne tombent pas en panne lorsque certains experts partiront et offrira une meilleure couverture et des solutions pour vos problèmes de sécurité et de confidentialité.

Lorsque vous décidez de construire ou d'acheter, je vous conseille de vous concentrer sur le coût d'opportunité. Il s'agit de la plus grande inconnue et de la plus grande dépense, et généralement, la réponse apparaît assez rapidement.