Règles des services Wikimédia

Ce document traite des principes (une application par exemple doit être observable et exposer des métriques appropriées) et non pas des règles d'implémentation. Des directives pratiques de mise en œuvre seront écrites pour détailler comment les principes énumérés dans ce document doivent être appliqués en termes techniques (par exemple, l’application doit exposer des métriques RED à partir d’un point de terminaison à /metrics au format prometheus, avec une convention de nommage précise). La raison de scinder les deux parties est que même si nous ne nous attendons pas à ce que les principes changent beaucoup au fil du temps, nous nous attendons à ce que les directives de mise en œuvre changent plus rapidement en raison de l’évolution technique.

Il existe différents aspects du cycle de développement et d’utilisation d’un nouveau service, et plusieurs d’entre eux doivent être aussi standardisés que possible à tous les niveaux afin de ne pas rendre la complexité de notre écosystème impossible à maintenir. En général, l’adoption d’une architecture non monolithique a ses coûts, et à moins que des normes ne soient maintenues concernant la façon dont les différentes applications doivent interagir et comment elles sont développées.

Plusieurs aspects du développement d’un service doivent être pris en compte :

• Règles du développement
• Contraintes de sécurité / confidentialité
• Déploiement de la production

Dans les quelques sections qui suivent, nous analyserons les critères qu'un nouveau service doit remplir pour chacune de ces catégories.

Règles du développement

Tout ce que nous développons doit être gratuit, ouvert à la collaboration et utilie par lui-même. Un nouveau service doit donc :

• Actually do something
• Être créé uniquement s’il n’existe pas de logiciel FLOSS bien conçu, bien entretenu et compatible sur le plan architectural qui offre des fonctionnalités comparables pouvant être adoptées et améliorées / modifiées si nécessaire.
• Évitez de dupliquer inutilement des fonctions ou des fonctionnalités fournies dans d’autres services
• Be licensed under an OSI-approved license
• Fournir un mécanisme de configuration qui n’implique pas de modifier le code distribué
• Utiliser un langage et un ensemble d’outils qui ont été approuvés par TechCom

Alors que certains de nos services ne seront utiles que dans le contexte WMF, dans d’autres cas, le service autonome est destiné à être distribué pour une utilisation générale. Dans ce cas, il doit avoir les propriétés suivantes :

• Avoir un processus d’installation et de désinstallation documenté conforme à nos directives de mise en œuvre
• Avoir un processus de mise à niveau documenté conforme à nos directives de mise en œuvre
• Être versionné à l’aide de semver
• Indiquez les versions de MediaWiki avec lesquelles il (le code) est compatible
• Fournir un mécanisme par lequel un soutien (communautaire ou autre) peut être demandé
• Fournir un mécanisme par lequel des correctifs peuvent être proposés
• Fournir un mécanisme permettant d’émettre des avis de sécurité publique

Sécurité et confidentialité

Toutes les fonctionnalités implémentées en tant que service indépendant, doivent avoir les propriétés suivantes :

• Minimise data collection for any type of PII
• Soyez conforme aux politiques de confidentialité et de conservation des données de WMF.
• Implement privacy controls that are at least equivalent to those of any calling service. For example, if the privacy controls of the calling service specify that IP addresses will not be stored for more than 90 days, the external service may not store IP addresses for longer than that time.
• Avoir une politique de confidentialité et des pratiques de confidentialité compatibles avec les propriétés WMF/Wikimedia
• Avoir réussi un examen de sécurité
• Avoir des ressources allouées afin qu’une réponse rapide à tout incident de sécurité soit possible

Déploiement de la production

Si le service autonome est destiné à être utilisé dans l’environnement de production Wikimedia, il doit se conformer aux directives ci-dessus, et en outre doit

• Être déployable avec les outils WMF standard (comme spécifié dans les directives de mise en œuvre).
• Avoir un propriétaire et un plan d’entretien continu. Si le propriétaire d’un service est manquant (parce que l’équipe est dissoute/a un objectif différent), un nouveau propriétaire doit être trouvé via le processus de gestion responsable du code
• Avoir une journalisation conforme aux normes WMF - spécifiées dans les directives de mise en œuvre du service
• Être en mesure de collecter et d’exposer des mesures opérationnelles conformément aux normes WMF actuelles spécifiées dans les directives de mise en œuvre.
• Avoir un dossier d’exploitation (runbook) à des fins opérationnelles.
• Prendre en charge un déploiement multi-centres de données actif-actif (ou actif-passif).

• Définir des Indicateurs de Niveau de Service (SLI) (en) et des Objectifs de Niveau de Service (SLO) doivent être convenus. Failure to meet said service level objectives SHOULD result action to bring the service back into operational agreed upon Service Level Objectives. The Service Level Objectives can of course be reevaluated and changed, but preferably not as a result of a violation but rather an informed process.
• Have pinned / pinnable dependencies that don't need to be downloaded at runtime and/or from untrusted source.
• Have backups and a restoration/emergency plan (if the service stores any data).
• Have users, or a plan to acquire users

Interaction de service à service

Services will likely interact with each other; if that is the case, measures must be taken not to make the whole system dependent on the failure of a single component. Il est également nécessaire que l'observabilité soit augmentée dans le flux des requêtes. Ainsi tout nouveau service qui doit être déployé en production doit :

• Degrade gracefully its functionality if it can't access another service. If that's not possible, maybe the new service should be logically tied to the other. An exception is explicitly made for the MediaWiki API, given quite a few services might depend on its availability to be useful.
• Be able to perform requests to a specific hostname/ip provided via configuration.
• Be able to use infrastructure middleware for inter service communication functionalities including, but not limited to, encryption and circuit-breaking. Alternatively, the service SHOULD implement those functionalities internally.
• Add the appropriate tracing headers to the request, according to the WMF standards specified in the implementation guidelines.
• Log actions via the production logging facilities.

Meta

This policy was established in March 2019 by RFC T208524.