ウィキメディアのサービスの方針

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

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

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

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

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

開発の方針

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

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

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

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

セキュリティとプライバシー

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

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

本番環境への展開

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

• (実装ガイドラインで指定されている) 標準的な WMF ツールを使用してデプロイできること。
• オーナーと継続的なメンテナンス計画を持っていること。 サービスのオーナーがいない場合 (チームが解散した/別の焦点を持っている場合)、コード スチュワードシップ プロセスを介して新しいオーナーを見つける必要があります
• WMF の標準に準拠したロギングがあること - サービス実装ガイドラインで指定されています
• 現在の WMF 標準に従って操作メトリクスを収集および公開できること - 実装ガイドラインで指定されています。
• 運用目的のw:ランブックがあること。
• マルチ データセンターのアクティブ アクティブ (またはアクティブ パッシブ) デプロイをサポートすること。

• サービス レベル インジケーターがサービスに定義され、サービスレベル目標が合意されるべきです。 サービス レベル目標を満たさない場合、サービスを操作可能な合意されたサービス レベル目標に戻すための措置を講じる必要があります。 サービス レベル目標は再評価および変更できますが、違反の結果ではなく、情報に基づいたプロセスによる方が望ましいです。
• ランタイムでダウンロードする必要がなく、または信頼できないソースからダウンロードする必要がない固定/ピン留め可能な依存関係があること。
• (サービスが何らかのデータを保存する場合) バックアップと復元/緊急対応計画があること。
• 利用者がいるか、利用者を取得するための計画があること

サービス間のやり取り

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

• 他のサービスにアクセスできない場合、その機能を優雅に劣化させるようにします。 できない場合は、新しいサービスが他のサービスに論理的に結びつけられるべきです。 ただし、MediaWiki API には明示的に例外があります。多くのサービスがその可用性に依存しているためです。
• 構成で提供される特定のホスト名 / IP に対してリクエストを実行できるようにします。
• 暗号化や回路切断などのサービス間通信機能をインフラストラクチャー ミドルウェアで使用できるようにします。 または、サービス自体でこれらの機能を実装する必要があります。
• 実装ガイドラインで指定された WMF 標準に従って、リクエストに適切なトレース ヘッダーを追加します。
• 本番環境のロギング設備を使用して、操作を記録します。

メタ

This policy was established in March 2019 by RFC T208524.