Project:Infrastructure/Service Catalog

= Service Catalog (DRAFT) =

A lot of this template blurb has been borrowed by Robin from a similar process elsewhere, and needs to be heavily edited.

Gentoo Linux provides services. These are listed in the draft Service catalog. Services can be external facing, or internal facing.

For an initial scope limitation, this is being restricted to services where the Infrastructure team are presently handling the operations of a service.

Services are staffed by people in different roles. Not all services require all roles. People may play multiple roles in a service, or the same role across multiple services.

Services deliver measurable value. Service catalog entries describe the service, define and help track these values, as well as how the roles are filled on the service, and other important service details. Some services are VERY big. Some are micro. They all at least have an identifiable lead, some measurable value, and a way to escalate a problem.

Services without an active lead should be considered as moribund. As original leads (staffer/developer/user) have retired from Gentoo, the Infrastructure team has historically become the default owner. This is not sustainable in the long term.

Services have Projects. Projects have defined starts and ends and involve members of cross-functional teams to either maintain or improve services and their value. Projects can be tracked on a timeline

About this catalog

 * Why is it important to identify and catalog services?
 * Identifying a service means making sure it is tied in with the Gentoo's strategy and objectives. Cataloging means there's some place to come back to on a regular basis to ask whether it's still critical, can it be improved or changed?
 * Identifying both internal and external services makes it clear the entire scope of projects, and where there are choke points and other critical pieces
 * Why is it important to identify roles and how they are staffed?
 * Important to know that services are properly staffed
 * Important to know if staffing changes, service is still staffed appropriately
 * Important to understand workload implications for staff across services

Roles & Responsibilities
Services are staffed by people in different roles. Not all services require all roles. People may play multiple roles in a service, or the same role across multiple services.

Role: Service Owner / Project Lead

 * Service Definition (SLA, EOI)
 * Contract creation, renewals
 * Resourcing
 * Project Management
 * Analytics and Reporting, and Open Data

Role: Support (Tier1)

 * Tier 1 client interaction
 * Documentation & Training
 * Testing & QA

Role: Application Administration & Operations

 * Account Administration
 * Other site admin and approvals
 * Configuration changes within the applications

Role: Application Dev and Maintenance

 * Initial Development
 * Enhancements
 * Bug Fixes
 * Configuration Management & Upgrades
 * Acceptance Testing (with Support)
 * Tier2/Tier3 Support

Role: Sysops

 * Capacity Management (monitoring, sizing)
 * Service Continuity (backups, recovery)
 * Security Management

Role: Administration

 * Costing / "sales" - Finance
 * Marketing & Communications
 * Governance
 * Human Relationships
 * Legal
 * Stakeholder Liaison

TEMPLATE: Service Name

 * Service Lead:
 * Service Description:

Metrics

 * Number of X in past month

Service Workplan
If there are development plans, this should link to it.

Support Details

 * Tier 1..3
 * Emergency (//help, it's down!//)

Application Admin & Operations Details
High level details for administration and operation of the service. Expanded details can go on a sub page or be pointed to in other parts of the wiki.

Application Dev and Maintenance Details
High level details for administration development for the service. Expanded details can go on a sub page or be pointed to in other parts of the wiki.

Sysops Details
High level details for systems support for the service. Expanded details can go on a sub page or be pointed to in other parts of the wiki.

Administration Details
High level details for Administration for the service. Expanded details can go on a sub page or be pointed to in other parts of the wiki. Ideal should include pointers to contract details, SLAs, EOI

LDAP

 * Service Lead: Senior Infra (robbat2 built most of it)
 * Service Description: LDAP services for authentication & authorization on Gentoo servers

Metrics

 * Availability

Support Details

 * Tier1: Bugzilla tickets to Infra
 * Tier2/3: LDAP skilled Infra staff
 * Emergency: Infra

Application Admin & Operation Details

 * Recruiters create new accounts
 * ComRel can do password resets and change some access
 * Infra can do password resets, but do not do new accounts as a general rule

Application Dev & Maintenance

 * Infra handles all development & maintenance

SysOps

 * Infra

InfraWiki

 * Owner: Infra
 * Description: InfraWiki houses sensitive infra-specific information. This includes IRL contact information for infra staff, sponsors, as well as sponsor-specific procedures and practices, and all infra hosts post a set of inventory data on a weekly basis.

Administration

 * Infra

CVS

 * TODO

Git

 * TODO
 * Mention overlays admins

Archives: Archives-AG

 * This is the new archives service
 * TODO
 * New service built by robbat2 and a3li

Archives: Mhonarc

 * This was the OLD Archive service
 * Broke
 * Did not have an owner for a long time

GitWeb

 * TODO
 * New service built by robbat2 and a3li

Torrents

 * TODO: describe dead services too

Packages Database: packages.g.o (v4)

 * Based on elastic search.
 * Git: packages.git
 * GitWeb: https://gitweb.gentoo.org/sites/packages.git/
 * Author:
 * Owner:

Package Database: packages.g.o (v3)

 * Needs a new owner
 * based on pkgcore
 * Git: packages.git
 * GitWeb: https://gitweb.gentoo.org/packages.git/
 * Author: jokey@gentoo.org

Package Database: packages.g.o (v2)

 * OLD, but never completed or launched
 * Author: marduk@gentoo.org
 * CVS gentoo/src/packages
 * Sources http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/packages/

Package Database: packages.g.o (v1)

 * OLD (???-2007)
 * Author: ???
 * Code: ???
 * SSI-based, insecure

Project Hosting

 * TODO: service not launched yet ;-)

Mirrorstats

 * TODO
 * Moribund, no owner to restore service