——————————————————————————–
(1) Maintenance Overview:
——————————————————————————–
1.1) Maintenance Objective:
1.2) Reason for the maintenance:
1.3) What should we (DevOps) check to confirm that the app is functioning before change?
1.4) Primary Point of DevOps Contact:
1.5) Primary Point of Dev Contact:
1.6) The team which owns the change: Dev or DevOps
1.9) Amount of time estimated for maintenance: 2 hour
1.10) Maintenance window overrun preference:
if overrun - should we rollback instead of proceeding?
1.11) Login method/user account: ssh after vpn?
——————————————————————————–
(2) Maintenance Steps:
——————————————————————————–
2.1) Call the Points of Contact and verify their availability 30 minutes before scheduled maintenance.
- DO NOT PROCEED UNTIL YOU HAVE CONTACTED THE Point Of Contact. *
Contact Information: <list the contact numbers of the team members in Dev and Devops>
2.2) Suppress alerts which may be triggered by the maintenance.
2.3) Record suppression in your maintenance ticket.
2.4) On your workstation, collect diagnostic information before running the maintenance. CPU / MEMORY / disk usage
document that in the ticket
2.5) < add specific steps for the maintenance>
2.6) Maintenance Objective Verification Steps
< list what you expect to see after the maintenance >
2.7) Post the diagnostic information to the maintenance ticket.
2.8) Update the ticket and call the Points of Contact stating the maintenance is now complete.
Contact Information:
2.9) Remove the alert suppression at this time.
——————————————————————————–
(3) Escalation procedure:
——————————————————————————–
3.1) If this maintenance plan produces unexpected results and / or will exceed
the scheduled time, escalate
Escalation point of contact (DevOps) - Escalation point of contact (Dev) -
3.2) If escalation does not provide a resolution, contact the Murali/ Allen by phone
to determine how they would prefer to proceed.
——————————————————————————–
(4) Rollback procedures
——————————————————————————–
4.1) < List out the rollback steps>
