Blog Slamdown Procedure
Web Log Status Page
orcmid>
BlunderDome>
B040801C>
0.00 2004-08-14
-22:16 -0700
|
|
Blog Slamdown Procedure |
|
The Web Log Status page is replaced with an incident marker so that anyone who checks that page at this time will see that there is an incident being addressed even though there is no other information. This is accomplished copying the incident-response-in-progress version atop the current version as easily and quickly as possible.
Create Incident Checklist
The incident checklist must be updated to reflect the actual steps taken, so that subsequent procedures can adapt to the approach taken. When the incident is being cleaned-up, this list will be used to ensure that any gaps have been filled in and the proper materials restored.
Some Variations
At the hosted site itself, using FTP, the current Web Log Status page is deleted and the incident-in-progress page is renamed to be that page. This leaves a hole that for the incident-in-progress that can be restored from the site image on a development machine. Note that the site cannot be updated from the image without restoring the previous page.
On the site image on the development machine, delete the Web Log Status page, rename the incident-in-progress page to be the status page, and transfer another copy of the incident-in-progress page from VSS for the site image. Transfer the substitute Web Log Status to the hosting site with FTP.
Eventually, this action will be taken:
On the development (FrontPage) web site, check out the Web Log Status page, select all, delete all page content, and then use the Insert | Component | Include Page ... menu dialog to select the appropriate incident-in-progress page as the interim replacement of the Web Log Status page. Check in this new page.
Synchronize the site image to the development web site, using VSS. This should result in a new incident-in-progress version of the Web Log Status Page and a restored version of the incident-in-progress page in the site image. These can then be transferred to the host site via FTP.
This leaves a stable version of the incident material on the site.
Restoring an Informative Web Log Status
variation: We might come directly to this step if we can do it quickly enough.
We might come here from slamming the Web Log Status, rather than updating the development version to carry the slam information.
On the development web site, as Initial Analysis reveals an initial status and more details of the actual incident, the working copy of the Web Log Status can be amended to reflect the new situation and the updated status information. The working copy should be restored to its last good values as needed, and then edited to reflect the incident and the new status of the web logs as a result.
The development Web Log Status page is checked out and then updated to the working copy status via Include Page ... menu dialog, and checked in. When this material is moved to the site image and then the host site, we are in a normal Web Log Status condition, whether there is an incident response underway or the incident has been resolved already.
|
You are navigating Orcmid's Lair |
created 2004-08-14-21:21 -0700 (pdt) by orcmid |