最近借着年中总结述职报告，对开发运维管理工作进行了总结，整理出以下的开发运维管理制度，欢迎大家提提意见。
第一节 总 则
第一条
为规范日常开发运维工作流程，提高开发运维的工作效率，降低开发风险、增强开发人员的责任心、风险意识，保证开发补丁的质量和规范，特制定本制度。
第二条
本制度适用于所有自主研发系统开发工作，所有自主研发系统相关的开发人员都必须遵守本制度。
第二节 日常管理
第一条
开发内部周例会：每周一早上9点钟，项目组自行组织相关开发人员参加，各领域开发负责人提前编写好双周滚动计划，按领域分别讲述上两周工作计划完成情况，以及后续两周需要完成的工作计划，并提出相关风险以及应对措施，对于计划中的延迟项需说明理由。
站立晨会：每天早上（周一与周会合并）8点50至9点钟（时间可以自拟），开发负责人自行组织开发人员参加。开发人员站立成圈，依次讲述昨天工作的完成情况，以及今天工作的计划和可能遇到的难题或者风险，便于开发负责人有选择地进行干预和协助。
第二条
JIRA 问题更新：每天早上开完晨会，各领域开发负责人督促开发人员更新JIRA问题状态，并与业务领域沟通，尽快关闭问题。
Git 代码更新：相关系统的源码必须使用Git （列出对应的Git代码仓库)进行管理，每天开始进行代码编写之前，必须先将Git的最新代码（master分支）更新到本地工程，每天下班前需要把开发的代码提交到本地的Git中进行版本管理，若与小组其他人共享一个FORK分支，则在下班前需要将代码提交到远程的FORK分支。
第三节 需求管理
第一条
明确系统各模块或者领域的需求对接人，需求对接人负责需求的把控和管理。
第二条
【1】Bug、需求录入
JIRA业务领域提交的开发需求，必须先录入到开发运维管理系统（以下简称JIRA）（列出开发运维管理系统地址), 业务对接人需将需求申请单或者需求相关的文档传到JIRA任务的附件中进行存档。
【2】需求对接、评估
由各领域开发对接人负责与业务领域对接人进行需求对接， 确认需求之后由业务对接人以邮件形式发出，需要与开发负责人进行交底，共同评估需求的可行性、风险点。
【3】编写上传开发方案，计划并指派任务
开发负责人编写相应的开发方案，并维护到JIRA，编排开发计划，把任务指派给相应的开发人员。
第三条
需求变更： 开发过程中需求发生变更时，要求业务对接人以邮件形式描述相应变更，并维护到JIRA，开发对接人进行评估，若对工期进度影响比较大，需以邮件方式回复变更对整体项目进度所造成的影响。
风险控制：根据开发方案，进行风险级别评估，涉及高风险的开发项，必须以邮件的方式告知业务相关人员，并抄送给相应的领导，各方协商同意后才可进行补丁开发，涉及产品改动风险较大的，需在开发方案中注明应对措施。
第四条
高风险开发需求定义： 涉及修改相关系统公共代码以及模块公共代码，高频后台任务、预警开发，对系统原有流程逻辑有重大变更，涉及资金支付、银企直联等；核心模块的代码改动需要注意增加分支判断。
第四节 源码及补丁管理
第一条
代码库更新：如果系统是基于代码库进行开发的，规定每月1号进行开发人员代码库更新，提前一天跟相关人员拷贝最新代码库，如果1号非工作日，则自动顺延到下一个工作日。
第二条
源码获取：在补丁开发阶段，更新JIRA任务状态，Fork git相应模块的最新master代码，确认所需要修改的类之后，优先使用Git上面已有的源码，若需要改的类在Git上面没有源码，则需联系相应的开发负责人，原则上禁止开发自己进行反编译。
第三条
Findbugs 代码自检：补丁完成开发之后，需进行单元测试，测试通过后，使用Findbugs进行简单的代码检查，并自行检查代码，确认无误之后，通知业务对接人在开发环境进行测试验收；
代码注释：开发环境验收通过后，将相关代码提交到git，按照规范写好相关备注和注释，注释必须使用中文人名全称，不能使用英文缩写等，如下：
单行注释：//Fixme: add /update by 张三 2016-10-25（修改日期） 增加或者修改的原因
多行注释：
//add /update by 张三 2016-10-25 增加或者修改的原因 begin
…..
…..
//add /update by XXX 2016-10-25 增加或者修改的原因 end
另外如果整个类都是新增的，需要在类的文件头标明：
/**
类的描述
@author 张三
@Time 2017-5-1 23:03:01
*/
补丁合并：开发人员在发出补丁之前必须先与相应环境的Git代码进行对比合并，打联测的补丁就与联测的代码进行合并，打正式的补丁就与正式的Git代码进行合并。
JDK 检查并打包补丁进行代码评审：若开发语言使用Java的，查看开发环境JDK编译版本是否与相应的业务系统运行环境一致，并按规定进行补丁打包（补丁命名），填写《补丁清单》，以邮件方式将补丁发给开发负责人或相应的代码评审专员进行代码评审，收到其中一人评审通过结果后，才能安排打入测试或者正式环境。
第四条
联测以及正式补丁窗口：需讨论确定相关系统的测试和正式环境的补丁上线窗口时间；当天有补丁上正式的开发人员，需保持电话畅通，保证能够快速定位、排查、解决业务测试人员反馈的正式补丁问题。可选择远程或者现场解决问题，涉及到重大更新补丁，相关开发人员必须在现场与业务对接人一同测试。
紧急补丁：在规定上线窗口时间之外需上线补丁的情况，必须由相关领域负责人邮件进行申请，相关信息化领导审批通过后才可以执行。
详见第六节。
第五条
补丁存档：补丁在正式环境测试通过后，在更新JIRA问题状态的同时，必须将补丁维护到JIRA对应任务的附件中进行存档（或选择SVN进行存档），包括补丁相关的数据库脚本、配置文件，更新JIRA任务的状态，各领域开发负责人在关闭问题时进行检查。
第五节 代码评审
第一条
联测和正式补丁必须进行代码评审，以邮件形式发给相关开发负责人，参加评审的补丁必须在打补丁的窗口日期前一天提前发出，依次顺延。
第二条
评审内容：
（1） 检查是否存在低级错误：JDK编译版本、空指针错误、数组越界、强制转换等；
（2） 检查是否存在高危代码：线程泄露、数据库JDBC连接忘记关闭、死循环、公共类和平台基类篡改等等；
（3） 检查是否符合代码规范：命名规范、注释、代码可读性、代码结构等；
（4） 检查代码耦合度；
（5） 检查代码可扩展性；
（6） 检查接口日志处理、异常处理、事务划分处理；
（7） 检查开发人员对应方案的熟悉程度；
第三条
奖惩机制：
（1） 代码评审过程中，第一次发现补丁中存在低级错误，需对补丁开发者进行指导教育，并且需要在每周的代码评讲中进行投影，第二次发生低级错误问题，予以相应金额的罚款（具体金额由项目组内部沟通确定），第三次发生低级错误问题，补丁开发者需调离项目组；
（2） 因补丁质量问题，导致正式环境发生大面积报错，但影响不大的情况，予以补丁开发者相应金额的罚款惩罚；
（3） 因补丁质量问题，导致正式环境发生大面积报错，严重影响系统业务或者导致系统宕机的情况，加重罚款或者直接将补丁开发者调离项目组。
（4） 代码评审发现某些开发人员写的代码比较优质，并且连续一个季度代码评审无出现问题者，可在总结会议中进行表彰（具体奖励形式视项目组内部讨论决定）。
第六节 上线流程管理
第一条
上线申请：
（1） 补丁的正常上线时间为下午18:00下班后，补丁上线前需发邮件知会给相关项目负责人。
（2） 除正常上线时间外，其他上线时间均为紧急上线，需发送邮件给系统负责人，得到许可后方可打补丁。
（3） 如补丁上线会导致系统停机中断，需在上线申请邮件中特别说明，并等待系统负责人发出停机公告后方可打补丁。
申请邮件：
（1） 上线申请邮件中应列出本次上线补丁的问题清单，清单格式参照附件。
（2） 上线申请邮件中应列出本次上线补丁对应的SVN归档目录
（3） 上线申请邮件中不得包含具体代码补丁，打补丁人员应从SVN目录中获得补丁。
上线过程：
（1） 批次补丁上线测试期间，如果其中某问题的代码出现问题回滚，打补丁人员应记录下来。
（2） 批次补丁最终上线后，打补丁人员需发一封补丁上线情况的邮件，记录本批次最终上线补丁和回滚补丁的情况。
（3） 批次补丁上线后，需增量把本次上线情况维护到整体上线情况清单中。
（4） 批次补丁上线后，需联系用户确认补丁生效情况，及时更系JIRA状态。
第七节 技术运维管理
第一条
每日技术运维巡检：
各领域负责人每天早上通过监控系统获得服务器运行状况，并截图监控系统界面，大致总结目前服务器运行状况，7点半前邮件发出知会相关项目负责人。
第二条
半年技术运维巡检：
每半年提供一份服务器技术巡检报告，从吞吐量、数据增长量、负载压力等关键指标对现有服务器情况进行分析，并提出结论。
第八节 附则
第一条
本制度自发布之日起开始执行。