Wikimedia services policy/ja

この文書では、実装ガイドラインではなく、原則 (例: アプリケーションは監視可能にして、適切なメトリックを公開する必要がある) を扱います. この文書に列挙されている原則を技術用語でどのように適用するかを詳しく説明するために、実用的な実装ガイドラインが作成されます (例: アプリケーションは、正確な命名規則を使用して、 エンドポイントからの RED メトリックを prometheus 形式で公開する必要がある). 2 つの部分を分割する理由は、原則が時間の経過とともに大きく変化することは期待しないものの、実装ガイドラインが技術の進化によりさらに迅速に変化することを期待しているためです.

新しいサービスの開発と使用サイクルにはさまざまな側面があり、エコシステムの複雑さが維持できなくなるのを防ぐために、それらのいくつかを可能な限り標準化する必要があります. 一般に、非モノリシック アーキテクチャの採用にはコストがかかり、さまざまなアプリケーションの相互運用の必要性と開発方法に関する標準が維持されていない限りコストがかかります.

考慮に入れる必要があるサービスの開発のいくつかの側面があります:


 * 開発の方針
 * セキュリティ/プライバシー要件
 * 本番環境への展開

以下のいくつかの節では、新しいサービスがこれらの各カテゴリで満たさなければならない要件を分析します:



開発の方針
我々が開発するものはすべて、無料で、共同作業に対してオープンで、それ自体が役立つものでなければなりません. したがって、新しいサービスは以下を行う必要があります:


 * 実際に何かをすること
 * よく作り込まれ、よくメンテナンスされ、アーキテクチャ的に互換性のある、同等の機能を提供する FLOSS ソフトウェアがなく、必要に応じて採用し、改良・変更できる場合にのみ作成されること.
 * 他のサービスで提供されている機能を不必要に重複させないこと
 * OSI が承認したライセンスであること
 * 分散コードの変更を伴わない構成機構を提供すること
 * TechCom によって承認された言語とツールセットを使用すること

一部のサービスは WMF のコンテキストでのみ有用ですが、その他の場合、スタンドアロン サービスは一般的な使用のために配布されることを目的としています. その場合、以下のプロパティが必要です:


 * 我々の実装ガイドラインに準拠した文書化されたインストールおよびアンインストール プロセスを持つこと
 * 我々の実装ガイドラインに準拠した文書化されたアップグレード プロセスを持つこと
 * semver を使用してバージョンを付けること
 * 互換性がある MediaWiki のバージョンを示すこと
 * サポート (コミュニティなど) を要求するためのメカニズムを提供すること
 * パッチを提案するためのメカニズムを提供すること
 * 公開セキュリティ アドバイザリーを発行するためのメカニズムを提供すること



セキュリティとプライバシー
スタンドアロン サービスとして実装されるすべての機能には、以下のプロパティが必要です:


 * PII の任意の種類のデータ収集を最小限に抑えること
 * WMF のプライバシー/データ保持ポリシーに準拠すること.
 * 呼び出し元のサービスのプライバシー制御と少なくとも同等のプライバシー制御を実装すること. 例えば、呼び出し元のサービスのプライバシー制御が IP アドレスを90日間以上保存しないことを指定している場合、外部サービスは IP アドレスをそれ以上の期間保存してはいけません.
 * WMF/ウィキメディアのプロパティと互換性のあるプライバシー ポリシーとプライバシーの実践を持つこと.
 * Have passed a Security review
 * セキュリティ インシデントに迅速に対応できるようにリソースを割り当てること



本番環境への展開
スタンドアロン サービスがウィキメディアの本番環境で使用されることを意図している場合、それは上記のガイドラインに準拠する必要があり、さらに以下を行う必要があります:


 * Be deployable with standard WMF tooling (as specified in the implementation guidelines).
 * Have an owner, and a plan for on-going maintenance. If the owner of a service is missing (because the team is disbanded/has a different focus), a new owner must be found via the code stewardship process
 * Have logging that conforms to the WMF standards - specified in the service implementation guidelines
 * Be able to collect and expose operational metrics according to the current WMF standards specified in the implementation guidelines.
 * Have a runbook for operational purposes.
 * Support a multi-datacenter active-active (or active-passive) deployment.


 * Service Level Indicators must be defined for the service, and Service Level Objectives should be agreed upon. 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



サービス間のやり取り
サービスは相互作用する可能性があります. その場合は、システム全体が単一のコンポーネントの障害に依存しないように対策を講じる必要があります. また、リクエストの流れの観測可能性を高める必要があります. したがって、本番環境に展開する必要のある新しいサービスは以下を行う必要があります:


 * 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.

メタ
This policy was established in March 2019 by RFC T208524.