Operations in a Distributed World - The Practice of Cloud System Administration - page 155

hardware qualification to test for compatibility, performance regressions, and
any changes in operational processes. ( Section 10.2 )
• Decommissioning: Turning off a service. It is the opposite of a service launch:
removing the remaining users, turning off the service, removing references to
the service from any related service configurations, giving back any resources,
archiving old data, and erasing or scrubbing data from any hardware before it
is repurposed, sold, or disposed. ( Section 7.2.2 )
• Project Work: Performing tasks large enough to require the allocation of ded-
icated resources and planning. While not directly part of the service life cycle,
along the way tasks will arise that are larger than others. Examples include fix-
ing a repeating but intermittent failure, working with stakeholders on
roadmaps and plans for the product's future, moving the service to a new data-
center, and scaling the service in new ways. ( Section 7.3 )
Most of the life-cycle stages listed here are covered in detail elsewhere in this
topic. Service launches and decommissioning are covered in detail next.
7.2.1 Service Launches
Nothing is more embarrassing than the failed public launch of a new service.
Often we see a new service launch that is so successful that it receives too much
traffic, becomes overloaded, and goes down. This is ironic but not funny.
Each time we launch a new service, we learn something new. If we launch new services
rarely, then remembering those lessons until the next launch is difficult. Therefore, if
launches are rare, we should maintain a checklist of things to do and record the things you
should remember to do next time. As the checklist grows with each launch, we become
better at launching services.
If we launch new services frequently, then there are probably many people doing the
launches. Some will be less experienced than others. In this case we should maintain a
checklist to share our experience. Every addition increases our organizational memory ,
the collection of knowledge within our organization, thereby making the organization
smarter.
A common problem is that other teams may not realize that planning a launch requires
effort. They may not allocate time for this effort and surprise operations teams at or near
the launch date. These teams are unaware of all the potential pitfalls and problems that the
checklist is intended to prevent. For this reason the launch checklist should be something
mentioned frequently in documentation, socialized among product managers, and made
easy to access. The best-case scenario occurs when a service team comes to operations
wishing to launch something and has been using the checklist as a guide throughout de-