Fault Genes Working Group
状态：活跃（@2016年5月）
主席：Nemat Bidokhti 和 Rochelle (Rocky) Grober
OpenStack基金会联络人：David F. Flanders <Flanders@OpenStack.org>
欢迎来到OpenStack故障基因工作组的主页。
请在社交媒体基础设施上使用#FaultGenes-WG标签引用此工作组。
目的
故障基因工作组的目标是成为OpenStack容错性的DNA。故障基因工作组支持任何希望帮助创建OpenStack故障模式分类的社区成员，该分类将用于从设计到OpenStack部署的各个阶段。此工作组支持运维人员和开发人员。通过识别可能发生的故障类型、报告方式以及故障的影响，帮助运维人员。通过指导他们需要注意什么以及如何在设计中缓解这些问题，来支持开发人员。如果您有兴趣使OpenStack更具弹性，请加入我们！
目标:
此工作组的意图是服务于运维人员和应用程序开发人员。
- 主要：运维人员 - 提供OpenStack故障、分析以及日志记录方式的见解。
- 次要：应用程序开发人员 - 我们的工作组的结果将支持日志组能够生成良好的错误代码。
工作组章程链接：https://docs.google.com/document/d/16Rc_Ye_qpHWfq4P2uaTaGldfYIEPlajfBAu4VxvJg1Y/edit#
沟通
当前通讯方式是电子邮件和电话会议。未来与成员的沟通计划将通过开放社区邮件列表进行。
- <user-committee@lists.openstack.org> (请在电子邮件主题行前加上“[FaultGenes-WG]”标签)。
成员
无需正式会员资格。请通过电子邮件将您自己和/或同事介绍给此工作组：nematollah.bidokhti@huawei.com
该组面向所有故障基因OpenStack社区成员和支持供应商开放。
历史记录
工作组的重要日期（按倒序排列）
- [请在此列表顶部添加#FaultGenes-WG的最新活动]
- 已经讨论过举办面对面工作组会议的提议，但日期尚未确定 - 待定
- 该组于2016年5月5日获得OpenStack基金会用户委员会的批准
- Wiki页面于2016年6月2日创建。
- 原始提案和提名呼吁草案通过以下方式完成：https://etherpad.openstack.org/p/Fault-Genes
- #FaultGenes-WG起源于2016年2月奥斯汀OpenStack峰会之前的对话，想法源于Nemat Bidokhti和Rochelle Grober。
Meetings
- 会议时间：太平洋标准时间上午8:00
- 会议日期：每周（星期四）
- 电话会议信息：会议链接：https://www.connectmeeting.att.com (会议号码：8887160594，密码：3773562)
美国免费电话：888-716-0594 美国付费电话：215-861-6199 其他国家/地区：全球会议接入号码 https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=3773562&accessNumber=2158616199#C2
资源和参考
- 我们的Google表格模板链接：https://docs.google.com/spreadsheets/d/1sekKLp7C8lsTh-niPHNa2QLk5kzEC_2w_UsG6ifC-Pw/edit#gid=2142834673
- 工作组章程：https://docs.google.com/document/d/16Rc_Ye_qpHWfq4P2uaTaGldfYIEPlajfBAu4VxvJg1Y/edit?usp=sharing
- 用例：https://review.openstack.org/#/c/317695
面对面会议
故障基因工作组计划在OpenStack设计峰会以及运维人员中期会议上举行会议（如果可能）。
- 第一次会议 - 2016年4月OpenStack峰会，美国奥斯汀：https://etherpad.openstack.org/p/Fault_Genes-WG
- 第二次会议 - 2016年10月OpenStack峰会，西班牙巴塞罗那：待定
IRC会议
为了获得最佳的全球覆盖范围，未来将举行IRC会议。
- 待定
术语表
- 故障 - 导致软件无法执行所需功能的条件（IEEE定义）。
- 错误 - ：实际输出与预期输出之间的差异（IEEE定义）。
- 失效 - 系统或组件无法根据其规范执行所需功能（IEEE定义）。
- 优先级 - 由业务规则定义。它定义了缺陷的重要性以及应该修复的优先级。
- 严重性 - 由缺陷造成的损害程度定义。它定义了缺陷对软件产品功能的影响程度。
- 编号列表项 P1 - 关键：中断导致关键功能无法访问或完全的网络中断导致服务可用性受到严重影响。没有可能的替代方案。（4小时）
- 编号列表项 P2 - 重要：关键功能或网络访问中断、降级或无法使用，对服务可用性产生严重影响。没有可接受的替代方案。（24小时）
- 编号列表项 P3 - 正常：非关键功能或程序无法使用或难以使用，对服务可用性没有直接影响，但会产生运营影响。有解决方法。（3天）
- 编号列表项 P4 - 低：应用程序或个人程序无法使用，但有解决方法或可以修复。（5天）
- 正常行为 - 存在清晰的警报和故障通知的故障。
- 异常行为 - 没有警报或通知的故障。
模板推荐和最佳实践
我们的成员推荐填写Google表格模板时应注意以下事项
- 确保您识别API版本 - 项目特定，因此可能是一组
- 故障表现的位置/方式（项目/日志文件/操作等）
- 包含关键消息的日志文件片段也很好（以及文件名称/位置）
- 故障发生之前注意到的异常行为 - 事后诸葛亮也可以。
- 如果已知，触发条件
- 任何部署可能过度压力/达到极限的迹象
- 相关的日志消息格式是否良好？上下文是否正确？
- 清理过程？
- 映射到/从Launchpad
- 受影响的组件/组件组合已安装？例如，Nova网络与Neutron网络
- 事件发生在哪个工作流程中？
- 拓扑
- 如何重现？
- 如何检测到此问题，我们是否可以拥有监控来在未来检测到它？
- 这是代码问题还是配置问题？日志是否有帮助？（Kibana仪表板示例？）
- 恢复过程是什么？
- 故障发生的频率是多少，或者在识别出前兆症状后是否被短路？
- 您认为对根本原因重要的其他架构功能（单元、区域、组件的单个或多个副本等）
- 如果所有这些都存在于错误报告中，请在此处放置错误报告链接以及指向报告中信息的指针（您可以将任何缺失的信息添加到错误本身并在此处指向该信息）
- 如果您已经遇到过此问题，但其他人提交了它，请用+1或其他注释，并评论您的经验有何不同。
- 确保如果您有评论，它们都使用唯一的颜色，以便可以将信息链接到单个部署，或者将差异信息放在故障的底部
