# Runbook操作步骤设计
Runbook中的每一步操作，都有明确的操作步骤、操作命令/脚本、串/并行标记、操作人、确认人、预估开始时间、结束时间、预估执行时长。切换方案不同，对应的Runbook的操作步骤也不同。切换方案可以分停服切换和不停服切换。不停服切换方案对应用架构的要求比较高，通常需要对应用架构进行大规模改造，所以业界普遍采用的切换方案是停服切换。下面以停服切换为例，介绍Runbook设计的注意事项。
- **设计正向操作步骤**
  依据切换方案，将正向切换步骤细化到文档中，需要考虑到以下几个方面：
  1. 停服之前需挂停服公告，充分考虑用户感知。
  
  2. 停服操作需考虑系统的可用性机制，部分系统检测到应用停止会有自动拉起功能，所以需先关闭可用性机制，防止出现应用一直无法停止的风险。
  
  3. 数据库切换时需要考虑数据一致性问题，要想切换前后数据一致，必须源端的数据先静止，然后断开增量同步任务，数据一致性对比方案需详细规划，是做行数对比还是做内容对比，不同对比方式对比时长不同，需根据表的重要性和切换时长综合考虑来确定数据一致性对比方案。
  
  4. 源端数据静止，除了停止应用外，还要考虑批处理任务和消息队列中的消息消费情况等。
  
  5. 应用和定时任务的启停经常有顺序，需梳理应用和批处理任务的启停顺序，避免启动顺序不当造成业务影响。
  
  6. 由于公网DNS的域名解析有缓存功能，所以通常会出现虽然系统已切换到目的端，但是仍然有访问流量转发到源端的场景。所以Runbook步骤需要考虑公网DNS缓存问题，建议保留一段时间源端到目的端的转发路径，并持续观测一段时间后，再切断此转发路径。
   

- **设计回退操作步骤**
  在切换过程中，出现严重问题无法短时间解决的必须进行回退，以恢复到切换之前的状态，避免对业务造成不可逆的影响。以下是设计业务回退步骤的关键点：
  1. 正向操作的每个步骤操作失败都可能导致回退，所以回退的可能场景会比较多，每个可能的回退场景均需考虑。
  
  2. 回退操作从整体上可以分为有损回退和无损回退。在目的端产生新数据之前的回退都可以是无损的，数据可恢复到切换前的状态。若目的端产生新数据，又无法将目的端的新数据反向同步到源端，则就是有损的回退，此时回退会造成一定的数据丢失。要想在目的端已产生新数据场景下采用无损回退，必须建立目的端到源端方向的数据同步任务。
  
  3. 对于较大规模场景的业务应用，回退还会涉及到全量回退还是部分回退。采用全量回退还是部分回退，需结合业务影响进行判断和决策。比如当天同时切换了10个应用系统和10套数据库，若某一套数据库切换失败是全量回退还是只回退这1套数据库，判断依据需要业务部门评估应用跨云访问数据库和应用之间跨云访问时延是否满足要求等。
   
总之，在设计切换Runbook时，要充分考虑回退操作，制定合理的回退方案和步骤，明确操作人员，并在执行过程中严格按照规定的流程和步骤进行操作，以确保切换过程出现异常仍然可以按照既定的步骤进行回退，避免业务受到更大的影响。