嘉为科技-k8凯发天生赢家

各行业信息化程度迅猛发展的今天，各大企业的信息系统也日趋庞大和复杂。为了保证系统的正常运行，企业的运维人员会通过相应的kpi（key performance indicator, 关键性能指标）对系统进行监控。当某些kpi发生异常时，能够及时发出告警，通知相关人员。一、监控告警系统的数据检测现状现有的监控告警系统大部分采用人工设定规则或阈值的方式来实现。在某些情况下，这些方法确实简单有效，但在中大型业务系统中，我们往往会面临更多的kpi数量，更复杂的kpi间的关联关系，以及更多样性的kpi型态（如下图所示：恒值型、周期型、持续波动型等）。不同kpi型态对比面对这样的场景，若继续采用人工设定规则或阈值的方法进行检测，不仅会消耗大量的时间成本，而且容易导致告警的误报和漏报。在引入具体检测方案之前，让我们先来了解指标异常检测。二、单指标检测和多指标检测在运维领域，指标异常检测根据不同场景和应用需求，可以分为单指标异常检测和多指标异常检测。1. 单指标异常检测● 检测原理：关注的是某个kpi的值是否异常。例如：kpi突变、抖动等。● 异常场景：单指标异常主要是kpi值突然发生了较大变化。例如：cpu使用率突然增加、内存突然降低等。● 检测方法：在工业界，单指标异常检测主要有基于统计学和预测的两种方法。① 基于统计学的方法：通常是设定阈值判断是否异常。例如：3sigma等。若kpi超过阈值，则判断为异常，反之则正常。② 基于预测的方法：是通过建模并预测kpi曲线，根据预测值与实际值之间的误差大小判断是否异常。例如：arima等。若误差较大，则判断为异常，反之则正常。本次，我们对单指标异常检测不做过多探讨。2. 多指标异常检测● 检测原理：关注的是某个实体的状态是否异常。如：服务器、设备等。● 异常场景：多指标异常检测场景主要有两种情况。第一种情况：是尽管每个kpi看起来可能并没有异常，但综合多个kpi来看，可能就是异常的。例如：一个人的身高是185cm，体重是50kg，分别看身高和体重，均是正常的，但这个人脂肪率严重偏低，因此我们判断这个人的身体很可能出现异常。第二种情况：是有些单个kpi表现异常，但整体来看可能又是正常的。例如：一个人去体检，他在测心率时比较紧张，导致心跳加快，从心率kpi来看，这个人有可能发生了异常，但其他kpi均正常，从医生的角度判断，这个人体检是正常的。● 检测方法：与单指标序列相比，多指标序列具有维度高、数据量大、指标间关系复杂等特性。主要有两种思路：第一种思路：是将多指标序列划分成多个单指标序列，利用单指标异常检测方法发现异常；第二种思路：是直接分析多指标序列，如将多指标序列按形状或时间分成多个子序列，同时结合聚类等算法发现异常。针对多指标异常检测，第一种思路相对成熟，但这种思路会丢失指标间的关联性信息，同时对每个kpi进行建模会带来更高的成本。因此，检测方案将围绕多指标异常检测的第二种思路进行展开。三、多指标异常检测分析方案该分析方案包括离线过程和在线过程，主要是通过判断多指标间的变量关系是否被打破来进行异常检测。若多指标间的变量关系被打破，则判断为异常，反之则正常。发现异常后，会对异常的kpi进行故障定位。（分析方案流程图如下图）分析方案流程图1. 方案流程① 离线过程● 基于sbd的dbscan聚类：使用基于sbd的dbscan聚类算法将相似指标聚类，可以降低分析框架的复杂度，并且将相似形状的指标聚类到同一类中。● sarimax建模：随后，在聚类后的每个簇中，对两两指标建立sarimax模型，构建指标间的不变量关系。不变量关系指时间序列间存在着不会随时间变化的关系，如指标1为sin(t)和指标2为sin(3t)的关系。② 在线过程● 异常检测：通过计算两两指标间的残差得分，再根据指定阈值判断不变量关系是否被打破。若残差得分超过阈值，则认为不变量关系被打破，即该指标对存在异常，反之则不存在异常。● 可视化不变量关系图：对离线学习和在线学习的不变量关系图进行绘制，可视化异常检测结果。● 故障定位：对所有被打破的不变量关系采用改进的pagerank算法进行故障定位。2. 验证方案为保证该方案行之有效，我们获取了某系统多个kpi数据进行验证。首先，观察历史kpi时序数据，存在部分数据形状相似，在经过聚类后，将具有相似形状的kpi分为一个类型，其他kpi归为噪音簇类。下图中左侧为部分原始时序图，右侧为聚类后的时序图。原始时序图和聚类时序图接着，对每个簇类的kpi构建不变量关系模型，根据实时数据判断预测。如下图中，左侧为在离线过程中，构建变量间的不变量关系图，并对簇类1和簇类2的中心点分别与噪音簇类构建不变量关系图；右侧为在线过程中，判断不变量关系是否被打破，如类簇1中6->4、6->17的不变量关系被打破，并通过pagerank算法将指标6定位为根因。离线不变量关系图和在线不变量关系图另外噪音簇类的大部分不变量关系均被打破，可根据实际业务确定是否分析噪音簇类。四、总结本帖介绍了通过构建不变量关系进行多指标异常检测可以处理大部分的异常场景，无论是单个指标异常，整体正常，还是单个指标正常，整体异常，均能有效的检测。在运维领域中，异常检测是其他aiops场景建设的基础，异常检测的结果将为后续的告警压缩、故障定位、故障自愈等场景提供重要输入。

在软件领域， agile和scrum一直是比较热的词汇，包括很多企业已经实践了敏捷很多年，但是实施效果一直不是很理想。那我们今天在谈论如何实施scrum之前，我们先确认一下，您的企业真的需要scrum吗？一、区别agile和scrumagile（敏捷开发）是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。它以敏捷宣言为基础，以敏捷开发十二原则为基础，构建了整个敏捷开发流程体系。scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。scrum包括了一系列实践和预定义角色的过程骨架。scrum中的主要角色包括同项目经理类似的scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。总结起来，scrum包括3355：1、三个角色：产品负责人（product owner）、scrum master、scrum团队2、三个工件：产品backlog（product backlog）、sprintbacklog、产品增量3、五种仪式：sprint计划会议、每日站会、sprint评审会议、sprint回顾会议（sprint retrospective meeting）、产品backlog梳理会议4、五种价值观：承诺、专注、开放、尊重、勇气scrum是敏捷开发中的一种方法论，全世界使用敏捷开发的团队大约57%在使用scrum框架。但是敏捷开发除了scrum框架以外，还包括kanban、xp、dsdm、fdd等框架。所以在使用scrum之前，一定要对agile和scrum之间做一下区分，想清楚您是真的需要做scrum，还是只想做到敏捷转型，但不一定采用scrum。二、团队内部，如何实施scrum？那回到企业内部该如何实施scrum，实际也有一定的前提条件和实施步骤可供参考：第一，首先需要组建全功能团队。首先这个团队可以基于实际的组织架构，也可以基于虚拟的团队形式。团队只有具备完成任务所有的职能角色，才能取得想要的效果。第二，在团队和业务部门对接的时候，收紧需求入口。只有这样，才会避免一个开发人员对接多个业务团队的现状。对于开发人员来说，他需要对团队内部的po负责即可，按时交付已经做好排序的需求功能，才不会被无休止的业务人员打断，也不用不停地在很多工作任务之间做切换。第三，把握需求粒度拆分，做好优先级排序。敏捷开发需要遵守固定的时间盒，这就要求产品功能的实现粒度需要控制，不同业务需求之间的粒度不能差别太大（例如有的业务需求实现需要40人天，有的业务需求实现需要0.5人天）。需求拆分完毕之后，每个团队还需要遵循相同的原则，对需求进行优先级排序。只有规则相同，大家才能统一遵守执行。只有做好优先级排序，开发团队才能按照重要程度交付最有价值的需求。第四，针对每一个需求或者功能，建立团队固定的开发流程。只有建立起统一的流程，并且把流程的每一个阶段都可视化，才能在团队内部实时同步每个人的工作内容和工作状态。大家分工协作，以固定的模式交付自己的开发内容。第五，不同团队、团队不同角色之间，不可避免地要出现相互协作。那么只有建立起统一的团队节奏，每个团队、每个人都按照固定节奏去完成工作任务，才能相互协作，保证整个团队的工作产出。

敏捷这个概念已经提出很多年了。它针对开发团队的角色做了划分，并且对各个角色的能力要求还很高，另外对工作流程，迭代周期都提出了理想定义，这实际上是对组织架构的一个颠覆。对于国内的很多互联网大企业确实已经取得了不错的应用效果，但很多传统行业转型过程中的企业并没有很好地去应用。那么我们看一下在传统企业内部推进敏捷转型落地的过程中，都存在哪些问题和阻力？首先在企业内部，无论做任何变革，都需要有一个过程。不同的人，针对同样一件事，由于个人立场不同，得出的结论也是不一样的。在敏捷导入过程中，也存在这样的问题。当团队初始使用敏捷的阶段，最大的问题就是团队成员的抵触情绪。抵触可以有多种形式，主动的或被动的，公开的或隐蔽的。主动抵抗可能仅限于少数脾气暴躁但与世隔绝的人，或者它可以蔓延到那些煽动不满和鼓动以阻止参与的人。“积极抵制的人可能会试图破坏这个过程，所以他们会四处乱说敏捷开发，试图说服人们放弃它。” 随着不满的蔓延，它会削弱士气，因此隔离抗议者并让他们加入是很重要的。但是实际上公开抵制并不常见，至少在决定采用敏捷之后不会。更多遇到的情况其实是被动抵抗。“被动的抵抗者假装顺从这个过程，站起来并口头上表达想法，但他们的态度是，'谁在乎？'”。因此在敏捷的导入过程中，如何引导团队成员去接受，去积极地实践敏捷是关键所在。同时我们应应当意识到，软件开发效能的整体提升，并不是敏捷完全能解决的问题。团队效能的提升，涉及到管理流程、技术架构、工具自动化等方方面面的因素，而敏捷只关注于需求与开发之间的管理流程的问题。基于团队不同的现状，敏捷也有不同的表现形式，这里就不作赘述但总体来说，企业做敏捷转型，仍然有一定的流程可以遵循。如果企业完全是从原来瀑布开发模式做转型，那么首先在团队层面需要引入看板方式，让团队能够很好的可视化现有流程。只有可视化现有流程，才能识别并优化团队的瓶颈问题。其次，当团队能够熟练使用看板以后，就可以把团队的组织流程转变成scrum。scrum比kanban模式的优点在于对团队的动作做了更多的规范化，这样更有利于团队建立统一的开发节奏。第三，当团队的组织流程运行顺畅以后，就可以在技术架构层面引入更多的实践，例如：优化团队的开发框架、修复以前的技术债等。最后，当团队级别的效能提升到一定阶段以后，就可以把敏捷相关实践拓展到整个it部门，并且推进业务部门一起来做尝试。这块就涉及到规模化敏捷推广和业务敏捷的相关内容了，后续我再详细展开谈谈。另外我们嘉为蓝鲸的devops平台完全可以实现敏捷开发，感兴趣的朋友也可以私我了解。

首先，回答怎么做之前，先思考要不要建立一个运维体系。这个和你的公司的现状有关。case1：公司规模小，有开发团队，没有运维团队：建议不要建立一套运维体系，而是基于devops的角度来思考。简而言之，在这种体系下，研发运维一体化，研发需要承接运维工作。尤其是当你们的业务是实时再线对外提供时，研发处理业务问题的效率要比运维高得多。简单介绍下devops：devopsk8凯发天生赢家的解决方案，是面向业务、需求、研发、测试、运维和运营团队的一站式研运一体化k8凯发天生赢家的解决方案。devops 需要具备高度扩展性和灵活性，支撑各种架构和稳敏多态等各种模式的研发流程，提供研发工艺的智能化引导、管控和度量能力；以高度自动化和资产数据流贯通能力，提升企业研发效能；以研发数字化k8凯发天生赢家的解决方案，助力企业加速实现数字化转型，提升业务竞争力。case2：公司业务规模大，但刚刚进行数字化转型，对数据有敏感性要求这种情况下，公司高层很难同意一套云原生的方案。在公司业务规模大，但it规模较小的时候，需要一套麻雀虽小，五脏俱全的运维一体化方案。其中需要包括：it基础设施的管理、it基础设施的监控告警，以及代码管理、软件打包与自动发布。这些产品虽然都有开源的方案可以使用，但摸索成本不低，对于一个没有运维团队的公司来说成本有些过高了。这种情况下还是建议买一套工具。这里还是建议站在巨人的肩膀上，嘉为蓝鲸针对it规模不大的客户，提供了一套一站式的weopsk8凯发天生赢家的解决方案，以上提到的能力都在weops中有机集成。weops的按照订阅制收费，对部门的现金流、预算影响比较小，可以推荐老板采购一套。在这种情况下，请通过云原生的方式来工作，即：业务基础资源请全部购买云资源，paas层包括中间件、数据库请都尽可能购买云上资源。像类似devops等其他的工具，建议购买成熟厂商的，避免自建。这些体系不是一个小公司，或者一个毕业生能够在短时间内思考清楚的。建议站在巨人的肩膀上解决问题。这里安利嘉为蓝鲸的devops及相应工具，蓝鲸已经在腾讯内部经过十年的大规模验证，工具能力强大全面，能够支撑新型业务团队敏捷迭代的诉求。case3：公司的业务规模和it规模都很大这种情况下我不相信你们没有it运维团队，但如果真的缺少一套面向大客户的，需要面对it系统海量数据与高并发的运维体系，那需要思考两个问题：自建还是采购。如果公司给你授权足够的hc、预算，且希望能够对运维技术自主可控，建议基于开源项目自建。开源项目这里包括自动化相关的工具，可观测相关的工具，协同与流程相关的工具。如果你不打算为此背负沉重的压力，同时公司只给预算，没给研发这套系统的hc，还是建议采购。这里还是推荐我们嘉为蓝鲸一整套itom与aiopsk8凯发天生赢家的解决方案，这套方案在腾讯内外已经经过大量甲方客户的验证，能够较好地满足大型it系统的运维诉求。

智能化运维近些年来开始被人们所熟知，我们专做it研发与运维，正好逛到这个问题，就来回答一波，希望能够帮到大家。一、智能运维（alops）概念：gartner在2016年时便提出了aiops的概念，aiops即人工智能与运维的结合，并预测到2020年，aiops 的采用率将会达到 50%。简单来说，aiops 就是基于已有的运维数据（日志、监控信息、应用信息等）并通过机器学习的方式来进一步解决自动化运维没办法解决的问题。软件的一些“算法逻辑”不代表真正的aiops，判断是否是真正aiops的关键点在于：是否能自动从数据学习中总结规律，并利用规律对当前的环境给予决策建议。总结一下就是：1. 智能运维是以大数据平台和机器学习（算法平台）为核心。2. 智能运维需要与监控、服务台、自动化系统联动，智能运维需要从各个监控系统中抽取数据、面向用户提供服务、并有执行智能运维产生决策模型的自动化系统。二、aiops的应用：通过对运维数据的计算和分析支持智能监控、智能的故障分析和处理，智能it知识图谱等。三、aiops的价值：传统运维面对海量的运维数据，要快速止损和进行决策，人工专家的分析判断往往需要花费数小时或更大。而aiops在于通过机器学习来进行运维数据的挖掘，能帮助人甚至代替人进行更有效和快速的决策。智能运维在企业的落地，能够提升业务系统的sla，提升用户的体验，减小故障处理的时间等，带来业务的价值；并最终实现真正意义上的无人值守运维。四、aiops应用领域：目前各大传统客户围绕aiops的探讨和建设主要是如下内容：发现问题：基于机器学习的异常检测；例如，目前监控数据的异常阈值往往是静态的，无法有效规避变更时间、特殊节假日、业务正常的高低峰等，简单阈值、同环比算法的覆盖面有限，很容易漏警和误警。基于历史数据或进行样本标记的kpi异常检测，能第一时间发现问题，检测模型能覆盖大多数曲线类型，能较好适应业务生命周期中的变化。根因分析：基于机器学习的故障树挖掘，定位故障发生的根源以及其原因；例如，首先实现故障精准定位，在多指标情况下的业务异常（多指标检测的异常），出现异常的原因具体是哪个指标导致的；然后根据故障树挖掘和知识图谱，实现故障的精准根因分析与定位。预测未来：基于机器学习模型的指标预测；例如，基于多种回归和统计方法，实现对不同级别粒度的业务数据的预测，包括业务指标预测、容量预测等，如双11业务对组件容量和资源容量的容量预测等。it辅助决策支持：深入运营场景，实现业务运营的it辅助决策应用；如营收预测、舆情分析与预测等场景。算法层面则可以跟学术界进行合作或在社区中获取，在早期训练数据集和反馈数据量比较少的情况下，采用无监督学习，具体实现是用模式识别（pattern recognition）的技术来判断指标是否关联。关联性是通过时间序列曲线相似度(similarity distance)来衡量的。机器学习算法库提供计算时间序列曲线相似度的各种算法，比如：欧几里德距离（euclidean distance）、曼哈顿距离（manhattan distance）、明科斯基距离（minkowski distance）等。在有足够数据集以后，算法演化成有：监督学习、随机森林（random forrest）、gbdt(gradient boosted decision tree) 、神经网络（neutal network）等。