精华内容
下载资源
问答
  • “点亮”风险应对的一盏明灯 项目风险应对时,你有没有经常在多个应对方案之间拿不定主意?又或者在多个应对方案中不知道重点在哪?本文将通过决策树分析法开启一些风险应对的“灵感”。 初 识 所谓的决策树分析,...

    “点亮”风险应对的一盏明灯

    项目风险应对时,你有没有经常在多个应对方案之间拿不定主意?又或者在多个应对方案中不知道重点在哪?本文将通过决策树分析法开启一些风险应对的“灵感”。

    初 识

    所谓的决策树分析,是在不确定因素的背景下,对可能出现的风险定量分析,用来作出有利决策的一个工具。通过在若干备选方案中对不同分支事件的产生的发展路径分析发生概率及产生的风险(包括威胁和机会),计算每条路径净值,根据预期收益选出最优路径。

    决策树分析的应用场景非常广泛,不经意中我们就已经用很多次决策树分析。例如买西瓜时我们可以根据纹理、根蒂及触感来挑好瓜;银行在审批贷款时根据借款人的信用情况判断是否能放款;新产品商业论证时面临多条发展方案时根据各方案的预期收益来决策。

    初 探

    PMBOK中关于决策树分析的计算方法的例子很详细。但肯定还有不少人跟我一样,看完那个例子并不知道如何下手决策树分析?来吧,我们探索一下决策树分析。

    1、决策树的要素与结构

    决策树分析的要素包括决策点(决策的出发点,可以有多个层级的决策点)、方案枝(决策的若干备选方案)、结点(每个方案枝在各种自然状态下的收益结果)、概率枝(每种自然状态对应的发生概率)及结果点组成。由决策点出发,从左到右根据需要决策的问题、可供选择的各种方案、各种方案的自然状态展现出决策树图。

    2、决策树绘制的前提与准备

    首先要明确有哪些备选方案:决策树分析要解决的是可选方案太多的“痛苦”,因此要先弄明白“痛苦”有哪些。举个简单例子,某个以新增利润为目标的项目交付过程中,业务方发现了新的商机,发起了一项需求变更,让业务方“痛苦”的可选方案有:

    1)、实施变更,但上线计划要推迟一个月,研发费用100万;

    2)、当前版本保持现状,下个版本(2个月后)实现新需求方案,研发费用新增80万;

    3、)当前版本实施临时方案,效果不能完全实现,下个版本(2个月后)再完成最终方案,研发费用新增120万。

    实际情况可能更复杂,某个备选方案自身可能就是一个决策点,这种情况就需要把这个决策点看成一个整体,绘制多阶决策树。

    其次要分析各项概率枝及预期收益:这是决策树的关键,直接影响着最终决策的准确性及有效性。

    这里有两个重点:

    1)、概率枝的考虑要尽可能全面,

    2)、各个概率枝发生的概率和预期收益要尽可能准确,可以借助结合数据、趋势、环境及专家评估等工具手段。

    继续前面变更的例子,三项变更实施方案,最主要的差异在于新商机方案投产时间对于收益等影响,通过对类似方案的运营情况及历史数据分析,方案3采用了临时方案的折中方案,可能会出现一定概率1200万的利润情况,方案1和2受投产时间影响,只可能会出现1000万和1500万利润情况。

    于是,通过上面两步走,决策树分析树基本可完成绘制:

    3、决策分析的结果与应对

    根据上面绘制的决策树分析图,计算出预期收益和期望值,方案1的预期收益最高,自然就是最佳决策方案。

    决策方案的确定并不意味着风险已经解决,只是在当前不确定因素前提下综合发生概率集影响作出的最佳决策,而针对其中的不确定因素还需进一步进行风险识别并记录到风险等级册,制定有效风险应对措施,增加正面预期收益的发生概率,降低负面收益的发生概率。

    引 申

    决策树分析还可以作为一种预测性分析的方法,通过分析当前和历史数据对未来的事件做出预测,提前“预演”未来事件,并根据发生概率有针对性地进行有效风险应对。

    进行预测性分析的关键点有两个:

    1)、对于决策结点进行有效分类,

    2)、决策结点的发生概率分析。

    1、决策结点的有效分类

    决策结点的分类,通常需要遵循以下原则:

    1)、结点包含的样本具有相同的属性;

    2)、结点中的样本属性无法再细分;

    3)、当前结点的已经是最终结点,无法继续划分;

    再来个例子:项目组识别到某个需求依赖外部合作方配合排期的风险,经项目组分析,对可能的结点进行归纳,绘制出下面的决策树:

    从上面的划分可以看出,不管是由谁去要求业务方去协调排期,都是同样的属性,都可以归类成同一类;风险解决的结点也不难理解,达到了我们风险应对的效果,无需再划分;上升到决策委员会则是风险解决的最终策略,无法再进一步划分。

    2、决策结点发生概率分析

    根据每个决策事件,进一步分析其发生概率,计算每个决策结果发生的最终概率,那我们就可以把更多的精力放到高概率决策结果的应对中去。根据上面每个决策结点的概率,易知最终调整我侧排期并跟相关方达成一致的概率最高,那我们就应将风险应对重点在这之前过程。

    总 结

    项目风险管理的核心是采取有效的风险应对措施,决策树分析法通过理性的数据分析为风险应对提供有效的决策依据,如果你经常拿犹豫不决,如果你经常不知道风险应对的重点在哪,试试上面的决策树分析法吧。

    需要项目管理资料合集的同学可留言

    展开全文
  • 公众号回复:干货,领取价值58元/套IT管理体系文档公众号回复:ITIL教材,领取最新ITIL4中文教材更多专业文档请访问 www.itilzj.com每个人都知道变更从来都不是件容易的事...

    55f9c5b78da70805a6a28b51967905c1.gif

    公众号回复:干货,领取价值58元/套IT管理体系文档

    公众号回复:ITIL教材,领取最新ITIL4中文教材

    6c7eb37a7ff56edea254fc22fc944027.png

    更多专业文档请访问 www.itilzj.com

    每个人都知道变更从来都不是件容易的事,但往往是非常必要的。这句话最真实不过了。

    坚实的变更管理能力将帮助您提高ITSM的成熟度,打破“消防模式”,使IT活动与业务目标保持一致,并将IT从服务提供者转换为业务创新者。然而,这些好处来之不易。变更管理是最困难的ITIL过程之一。为什么?因为变更管理是一个ITSM过程,需要人员、过程和技术的正确组合。

    可以把ITIL变更管理看作是一张三条腿的凳子。如果一条腿无力,凳子就会倒下来。

    首先,变更的定义:添加、修改或删除任何可能对IT服务产生影响的内容。

    这一定义提出了三个与变更相关的问题:

    • 为什么:变更的原因。您希望通过变更实现什么商业利益?

    • 什么:是硬件、软件、系统架构、过程、文档,还是这些的组合会受到变更?

    • 影响:这种变更可能带来哪些负面后果(请记住当今计算机系统复杂的相互依赖关系) — 以及如何避免这些后果?

    稳固的变更管理能力是基于对这三个问题的合理理解。从本质上说,实现一个成功的变更管理过程是关于提出正确的问题,并拥有合适的人员、工作流程和技术以快速有效地得到答案。正确的问题通常包括:

    • 做出变更的代价是什么?

    • 收益是否大于成本?

    • 变更的业务优先级是什么?

    • 我们如何实现变更?

    • 谁来实现这个变更?

    • 我们应该在什么时候实现变更?

    • 如果变更出错了怎么办?我们有后备计划吗?

    可靠地回答这些问题是最难的部分;实现变更更容易。

    变更管理和配置管理

    ITIL建议将变更管理与配置管理结合起来实现,但是在开始进行变更管理之前,您不需要实现100%的配置管理。关键是要理解两者之间的接触点。简单地说,变更管理需要一个基础结构的视图来评估变更的影响。配置管理需要记录变更,以便配置管理数据库(CMDB)保持最新,并始终表示实时环境。

    在本文中,您将阅读关于在组织中实现成功的变更管理过程的六个简单步骤,以及对工作流、分类、变更类型等的详细描述。

    确定您想要实现ITIL变更管理的原因

    在我们深入讨论这个话题之前,看看这些成功实施变更管理的技巧和技巧,以清楚地了解你应该做什么以及为什么要做。所有与实施变更管理有关的活动都应集中于实现上述目标。如果某件事不能与这些目标中的一个联系起来,它可能就不是优先考虑的事情。写一个要点总结为什么你需要做变革管理,把它打印大一点,贴在墙上,让每个人都能看到,这可能会有帮助。

    你知道你必须不断地变更。但是,变更的问题在于,有时候人们并不容易接受变更并取得成功。

    - Frank Calderoni

    成功因素:

    • 通过在高级别上销售利益和目标,获得执行人员对您的变更管理实现的支持。

    • 同意禁止未经授权的变更,并给予变更管理职能制定决策和处理阻力的权力的高层变更策略。

    变更管理重要性

    如果您希望提高基础设施的稳定性、服务质量和IT灵活性,那么变更管理就是“必要之恶”。它之所以不受欢迎,是因为它从根本上讲是为了维护控制权。IT人员已经认为他们经常被告知如何做他们的工作,所以添加一些像繁琐的变更控制过程只会减慢他们的速度。

    8d66e545e1f34c63344af740252bdfbf.png

    为了成功地进行变更管理,您需要确定哪些人将受到您所提议的变更的最大影响,并让他们在项目中进行投资。

    - Frank Calderoni

    麦肯锡对2000多名高管进行的一项全球调查显示,只有不到50%的受访者实现了他们最初的变革目标,并实现了这些目标。实现ITIL变更管理更多的是关于组织的变更而不是技术操作的变更。像任何其他的组织变更一样,您必须向利益相关者群体推销其价值,他们将受到实现的影响,并让他们参与进来。识别WIFM因素。每个人都在问“我能从中得到什么?”回答这个问题是很重要的。一个好的起点是列出将受实现影响的不同组的列表。接下来,分析他们做了什么,如何做,以及他们会有什么变更。然后,让每一个小组知道他们将会得到什么以及他们将如何受益。

    成功因素:

    • 在你说“什么”之前,先说“为什么”。

    • 对于每一个利益相关者群体,回答“它对我有什么好处?”

    识别什么是ITIL变更管理及其类型

    当你使用“变更”这个词时,不要期望每个人都能达成一致。它对不同的人意味着不同的东西,所以有一个明确的变更模型的定义是至关重要的。ITIL建议定义一个变更模型,该模型根据范围、影响和紧迫性将变更划分为组。

    变更管理是关于平衡进展与风险的,因此变更模型是有效变更管理的一个基本部分,使低风险的变更能够以最小的成本和资源使用快速应用。如果没有这个区别,所有的变更(无论多么微小)都必须经过一个完整的过程,这可能意味着把人们与微小的变更捆绑在一起,而更大的、更具变革性的变更可能会被推迟。变更模型中的典型级别可能包括以下内容,但可以根据您的组织进行调整:

    变更管理的类型

    在一个组织中有五种类型的变更管理

    • 标准的变更

    • 微小变更

    • 正常的变更

    • 重大变更

    • 紧急变更

    标准的变更

    具有定义良好的执行过程的简单、低风险的变更和服务请求不需要变更管理的评估,可能只需要请求者的直线经理的批准。最简单的变更类型(例如密码重置)可能根本不需要任何授权。标准变更不会生成变更请求,因为变更管理不会评估它们。相反,为了最大限度地提高效率,应由一个自动服务请求系统或服务目录来处理标准变更,要求自动触发一个工作流,将实施行动路由到相关技术小组。

    微小变更

    小的变更风险相对较低,但有一些有限的潜在影响。因此,他们将需要一个正式的RFC,并调用一个简单的变更管理流程来平衡风险水平与成本和资源。对于这些变更,规划和批准可以完全由变更经理处理,而不涉及变更咨询委员会(CAB)。

    正常的变更

    正常的变更会对服务的连续性造成中等程度的风险,需要召集驾驶室进行评估,并按照一个全面的变更管理流程进行计划。

    重大变更

    主要的变更在业务收益、规模和风险方面是显著的。重要程度和风险是众所周知的,所以一个主要的变更将涉及到大量的人来评估、计划和执行它。由于风险较高,一个主要的变更通常会升级到更高的变更权限进行审批。

    紧急变更

    紧急变更是那些必须快速执行以响应即时需求的变更,例如中断业务操作的问题。因此,紧急变更不仅给业务带来最大的风险,也带来最大的好处(如恢复业务连续性)。

    我们将召开应急部门(ECAB)会议,迅速、果断地应对此类紧急情况。处理紧急变更的程序将得到精简,重点是在考虑到使问题复杂化的风险的同时尽可能迅速地进行变更。因此,一些测试将在实现之前执行,但更全面的测试和调整可能会在实现之后持续一段时间。

    当根据您的变更模型对变更进行分类时,最好谨慎行事。将带有未知风险和影响的变更映射到变更模型的高层(例如,普通或重大),以确保对潜在影响进行全面和彻底的评估。在过程的最后,评估阶段将确定变更类别是否可以在模型中向下移动一层,例如,成为一个标准的变更,以便下次可以更迅速和有效地处理。

    成功因素:

    • 传达一个管理认可的策略,以确保对IT基础设施和服务的所有变更都通过变更管理运行,并停止未授权的变更。

    • 实施变更模型以确保成本和敏捷性与风险相平衡。

    变革管理需要有纪律的方法来控制变革,并得到官方政策和执行机构的支持。变更管理功能需要在整个组织中强制实施过程的权力。

    定义变更管理角色和职责

    过程需要人们采取行动并做出决策。也就是说,明确定义的角色和职责是确保所有权得到维护和顺利执行的必要条件。那么,您需要谁来支持您的变更管理过程呢?

    变更经理

    变更管理不是一个流行的功能(特别是在实现的早期阶段),因此需要特定类型的人来填补变更管理的空缺。那些寻求声望和积极反馈的人不用申请。在中小型组织中,变更经理不一定是专门的角色。有时问题管理人员或配置管理人员可能会承担这个角色,尽管当一个人拥有变更和更新CMDB的权限时,会涉及一些潜在的风险。事件经理/服务台经理不应该被提名为变更经理,因为这两个角色之间存在利益冲突。在较大的组织中,变更经理角色可能采取指导小组的形式,由对授权拥有最终决定权的变更领导领导。一般来说,变革管理者需要高度组织性、沟通能力、外交能力、理解力、决断力,最重要的是,厚脸皮。

    深入的技术技能不是必需的,但在与技术团队沟通时肯定会有帮助。变更经理负责评审提交的rfc,安排CAB会议,批准变更,更新变更记录,协调变更的构建/测试/实施,评审已实施的变更,生成报告,并改进变更过程。

    2106beb5f9a801d4bac39b3bf0a4efc3.png

    确保你有关键的人,特别是那些在关键岗位上的人,他们是你的驱动力。他们明白你想要完成什么,他们是自愿的参与者,而不是抵抗者。这会给你克服困难的动力。

    - Frank Calderoni

    变更授权

    每个变更在实现之前都需要正式的授权。根据规模、成本和风险,需要一个适当的变更授权来提供此批准。显然,纠缠CIO批准密码重置是不合适的,终端用户批准网络交换机升级也是不合适的。对于标准变更,变更权限可能是请求者或他/她的部门经理。对于一个小的变更,变更经理很可能是合适的变更授权人。对于正常的变更,CAB和变更经理将共同组成变更授权机构。而对于重大变革 — 那些具有重大规模、成本、效益和潜在业务影响的变革 — 变更权力可能是董事、c级经理,或者实际上是董事会。

    变更谘询委员会(CAB)

    CAB的职责是从业务、技术和财务的角度评估每个变更,并对其影响、规划和批准提出建议。CAB成员是灵活的,它从IT运营、开发和业务中吸引人员,以确保在讨论个人变更的实现时,所有角度都得到体现。变更经理将根据相关变更的性质决定哪些CAB成员参加会议。围绕个别变更的CAB会议可以虚拟地进行,但核心的CAB团队也应该定期开会,以审查政策和程序、正在进行的变更以及变更backlog。

    紧急变更谘询委员会

    ECAB(指通过ITIL作为出租车紧急委员会或出租车/ EC)是一个较小的,出租车核心组成员,可以在短时间内响应紧急变更,必须在短时间内(可能还在正常工作时间以外的)解决紧急问题。ECAB是紧急情况变更的变更机构,必须具有在紧急情况下不进行升级而作出决策的权力。

    成功因素:

    • 明确定义的角色和职责。

    • 较强的组织变更管理能力。

    • 管理人员赞助,以应对变革的阻力。

    • CAB必须代表IT和业务上的所有涉众群体,包括业务经理、终端用户、开发人员、系统管理员、服务台、客户和供应商,以适应每个单独的变更。

    • 当发生与变更管理和其他服务管理流程相关的交互时,需要员工之间有明确的交互和良好的理解。

    设计ITIL变更管理流程

    RFC需要通过一个管理的过程来指导决策制定和执行,以取得成功的结果。正式的变更管理流程对于以快速、资源高效、低风险的方式实现变更至关重要。

    变更管理过程永远不会在第一次就完全正确,但是有一些过程总比没有过程好。如果初始流程不足以管理变更,您仍然会看到失败变更的发生率很高。失败的变更意味着IT部门的额外工作、对业务生产力的影响以及收入的损失。如果你在你的变更管理过程结束时回顾它的执行情况,你可以在下次的时候对它进行调整。随着时间的推移,它会变得更有效率。

    ITIL非常关注变更管理的流程方面,因此咨询ITIL V2服务支持或ITIL V3服务转换卷是明智的,但是ITIL推荐的典型流程如下:

    • 记录 - 对基础结构的所有变更都必须通过提交变更请求(RFC)来记录。

    • 检查 - 变更管理人员充当看门人,快速检查每个RFC以决定是否继续执行。它是有效的、具体的、有益的、可行的和必要的吗?如果是这样,RFC将被接受并分类。否则,它可能被拒绝并返回给请求方。

    • 评定 - 变更经理和CAB(包含来自业务、用户社区、开发、支持和任何适当第三方的适当代表)将评估成本、资源、收益和风险(包括对服务的影响),并计划变更的执行,包括一个退出过程。

    • 批准 - 根据CAB的建议,变更经理将授权变更或将其升级到更高的管理层级进行授权,这取决于变更的类型和潜在影响。一旦授权,该变更应添加到Forward Schedule of Changes (FSC)中。

    • 协调实施 - 变更经理的责任是协调变更计划的执行,包括确保构建、测试和实现行动在正确的方式和正确的时间按照FSC的约定和发布。

    • 评估并关闭 - 如果变更成功,将会关闭RFC,并展开实施后检讨,以评估变更的益处,以及变更过程对实施的支持程度。PIR将回答诸如此类的问题:变更是否达到了目标?大家对结果都满意吗?有什么副作用吗?实现是否超出了计划成本、资源使用或停机时间?变更管理过程的持续改进就是在这里发生的。从经验中吸取的任何教训都可以反馈到过程中,使其更有效率。

    2fe9ea80fc324f11c3d5c8dd08829ea9.png

    成功因素:

    • 与IT和业务部门沟通变更流程,以提高理解并减少绕过流程的未经授权的变更的数量。

    • 大多数组织将需要工具来记录RFC、执行自动分类、触发和管理流程工作流,并支持基于面向服务的基础设施视图的影响评估。

    • 发布一个FSC — 所有经过授权的变更的日历 — 在一个可以让所有业务人员访问的地方。

    • 确保每个RFC都使用唯一的引用号和日期戳进行了日志记录,其中包含尽可能多的关于什么是变更以及为什么需要变更的细节,还引用了产生变更的项目或问题记录。

    • 不要在没有回退计划的情况下实现任何变更,这样可以在变更失败时快速回滚到稳定的配置。

    • 确保变更和取消计划在一个安全的环境中进行测试,例如,一个尽可能接近真实环境的沙箱。

    • 在评估阶段嵌入持续改进以随着时间改进过程。

    度量变更管理KPI

    变更管理是实现最困难的ITIL过程之一,但也是提高IT成熟度的最有价值和最关键的过程之一。为了保持势头,报告变更管理功能所交付的业务价值是很重要的。关键性能指标(KPI)将因组织的不同而有所不同,但以下度量标准通常表明变更管理的工作情况以及它给服务管理和业务带来的价值。

    关键绩效指标指:

    • 成功变更的数量

    • 回滚失败变更的数量

    • backlog中的变更数量

    • 由变更引起的事件数量

    • 紧急/超时变更的次数

    • 已识别的未经授权的变更数量

    • 用于变更的资源和资金

    • 根据FSC发生的变更百分比

    成功因素:

    • 定义一组与您的组织相关的KPI。

    • 使用KPI定期向业务和特定IT组传达变更管理的价值。

    结论

    一个可靠的ITIL变更管理流程意味着它可以安全地对来自业务的更多变更请求说“是”,并且可以摆脱“无部门”的形象。通过变更管理,IT部门可以快速提高基础设施质量,减少服务中断,并对业务做出更好的响应。企业无疑会注意到这种差异。

    通过遵循这6个步骤的实现过程,您可以提高成功实现的机会,缩短实现价值的时间,并获得对进一步ITSM过程工作的支持。

    • 确定您想要实现ITIL变更管理的原因

    • 理解变更管理的重要性

    • 识别什么是ITIL变更管理及其类型

    • 定义变更管理角色和职责

    • 设计ITIL变更管理流程

    • 度量变更管理KPI

    福利

    圈子构建、学习资料获取1000+份【ITIL/数字化转型/IT管理各类文档解决方案报告】,欢迎加入知识星球(扫下方二维码~~~

    40aac992599d4a16f7ac675a37a6eeaf.png

    更多推荐

    AIOPS趋势下的CMDB建设方向、思考与实践

    ITSM流程管理:如何有效实施

    ITSM(IT服务管理)流程五大阶段

    ITIL事件管理与问题管理的区别

    如何写好项目管理应聘简历?

    大型企业的智能运维之路(资料下载)

    ITIL&ITSM与OA的区别和价值

    更多专业文档请访问 www.itilzj.com

    免责声明:

    本公众号部分分享的资料来自网络收集和整理,所有文字和图片版权归属于原作者所有,且仅代表作者个人观点,与ITIL之家无关,文章仅供读者学习交流使用,并请自行核实相关内容,如文章内容涉及侵权,请联系后台管理员删除。

    868aa396e1c7c49bae8ec5626ffdde57.png

    展开全文
  • PMP面试题整理

    千次阅读 2021-02-28 08:44:30
    根据:管理计划、经验教训知识库、事业环境因素 通过:专家判断、头脑风暴、假设条件和制约因素分析 识别风险(人员变动风险、员工休假风险、需求变更风险等、组织调整风险等) 45 需求变更管理的手段和与客户沟通...

    1 你认为项目中最重要的是哪些过程?

    越是前期越重要,对项目影响越大。启动阶段:如果一个难以成功、难以盈利的项目被立项。事物发展的不确定性,极有可能导致项目夭折。(项目经理应该用自己的专业知识,影响高层;即使影响不了,应该在书面上留下自己的意见。

    对于项目生命周期而言:规划、监控过程。(规划不合理:极有可能导致项目事倍功半、甚至举步维艰。监控松散:导致项目偏离预定轨道,一来一回浪费双倍资源和时间。)
    对于软件生命周期而言:设计、需求调研、测试(人月神话:1/3计划,1/6编码,1/4单体测试,1/4系统测试。)

    2 如果给你一个4-6个人的Team,那么你怎么分配他们、管理他们?

    团队中必须至少要有一个技术过硬的队员,分配重要但不紧急的任务,在工期上安排一定的管理储备时间(有一定的指导作用,同时具有机动应急作用)。
    整体工作安排:每次安排一周的工作任务,每日由队员汇报进度。后续根据个人完成情况,调整工作安排。
    最后根据公司制度:制定奖励措施(资金奖励、名誉奖励、评级奖励)

    3 简述常用的软件开发文档?

    1、可行性研究报告
    2、项目规划说明书
    3、软件需求说明书*
    4、概要设计 *
    5、详细设计*
    6、数据库设计*
    7、用户手册
    8、操作手册*
    9、测试计划*
    10、测试分析报告
    11、项目进度月报
    12、项目总结报告

    4 你认为一个项目如何进行才正确?

    尽可能的以最小金钱,最少时间完成项目。但有利于项目发展的必要团建、奖金不可或缺。工时安排上,要顾及人员必要的情绪。

    5 你经常看或仔细研读过的书有哪些?

    java编程思想、孙子兵法、pmbok

    6 你认为你应聘我们公司的项目经理,你自身的优势在哪?

    1、性格沉稳:习惯性校验、重要事情两次检查,减少失误可能性。
    2、思路清晰:主次轻重分明,思虑周全。
    3、与人融洽:真心实意的站在客户、组员位置上思考问题。大事情上依法办事,细节偶尔谅解客户失误,也能得到客户的谅解。
    4、言简意赅:交流上、文字交流上,尽量简明扼要。
    5、多年全栈开发经验:项目各个环节均有了解。
    最近一个项目报表功能开发:难点:需求不明确、取数复杂(多系统、多阶段取值)、难以核对(老报表常有手工台账有误、取值不严谨有误差;系统功能不完善,数据库数据有误;新报表无核对数据,业务人员只能经验上给大概参考数据,甚至参考数据有误)
    解决方案:
    1、固化一个月数据,给报表核对
    2、增加人员辅助开发依赖功能、学习excel公式用于核对台账数据。
    3、请求上级部门交涉:让业务部门可能花时间安排报表验证工作、及需求明确工作。

    7 工期和工作量之间的差异是什么?

    工期是日历天数
    工作量是人天

    8 怎样和为什么要在编制项目计划时考虑依赖关系?

    只能先开发后测试。依赖关系决定了项目的关键路径,也就是项目的最短工期。也就是工作中重点关注的地方,优化关键路径,可以缩短工期。

    9 你怎样将人的工作步调与计划结合?

    细化工作包,拆分成更小的任务。

    10 你怎样将培训,假日和个人教育时间表结合起来?

    如果项目需要培训,应该把培训像任务一样写在项目计划里。培训毕竟是提高个人能力的事情,安排周末搞一天培训,员工抵触情绪大大降低,增加认同感、归属感 。

    11 你怎样安排类似状态会议这样贯穿整个项目但只需要极少的时间和工作量的任务?

    任务再小也应写在计划里。

    12 实况报告对计划的作用以及实况与最初预计的比较有何价值?

    感知项目进度,提前量滞后量。如果滞后则找出原因,计划不合理、执行有偏差,记录并找出解决方案,向变更委员会提交变更。

    13 你为什么制定项目计划?

    虽说计划赶不上变化,但走一步看一步是很难成功的,遇到问题不知所措、走错方向。
    我们有个人经验、组织知识库、行业经验:极大提高计划的正确性、准确性。
    同时计划使我们方向明确、资源、进度明确。
    规划风险应对:也有利于我们处理风险。
    计划:有利于我们合理安排资源、尤其是一些稀有关键资源的预定。

    14 你将怎样着手做项目的计划?

    计划安排是一门艺术:根据已知项目相关事实、公司一般标准、组织知识库、行业最佳实践。
    1、可以较为清楚的从范围入手:
    将项目所需的工作分解成工作包、规划包,再细分为具体任务。
    清晰可交付成果。
    2、整理项目的风险和制约因素。
    3、根据范围制定项目进度:
    找出任务依赖关系、优先级排序;找出项目的关键路径,制定项目关键里程碑。
    参考紧前关系图、资源日历:将任务与资源关联(如需培训,则把培训写在工作日程里)。
    (后续 成本估算、质量计划、资源管理计划、客户及内部沟通计划、干系人管理计划)
    4、将计划草案与团队、管理层、客户一起复查,以待补充性输入、最终批准。

    15 怎样确定人员需求?

    1、制定关键路径,确定项目进程数。明确项目一般人员数量、种类、级别。考虑到资源受限(人员变动、休假、紧前活动滞后),为每个任务准备15%的管理储备时间。
    2、由技术过硬人员、带领技术较好、学习能力较强人员:组成机动组。平时负责重要但不紧急的任务、人员培训、技术攻克、紧急协助。

    16 在决策和工作风格方面你会给你手下多大的自由?

    看个人专业技能水平,以及个人工作风格。
    1、专业技能强、工作积极的队员,可以适当给予更多自由。
    2、一般队员自由方面,还是要慎重(放权未必感激,收权必有怨念)。权衡利弊是否必要,无法权衡的话:可以小范围、短时间内试行。

    17 给项目加上测量标准有什么价值?

    测量标准应该是行业最佳实践,或接近行业最佳实践。具有极大参考价值。
    项目中测量:测量结果作为后续项目输入。明确当前项目是否偏离既定轨道(范围是否有镀金、遗漏,进度是否落后,后续资源是否需要调整,决断是否合理),
    极大提高项目成功可能性。
    项目后测量:有利于丰富组织知识库、有利于总结经验教训。

    18 你怎样在计划中运用新技术?

    将培训添加到计划里。
    添加额外模型、里程碑:观察新技术对项目的实际影响,以便尽早做出调整。

    19 你作为项目经理要做的第一件事情是什么?

    作为项目经理,项目的成功是第一位。首先要了解项目的目的(项目与公司愿景的关系)。其次才是项目要做什么,怎么做,需要什么资源。

    20 当你的职员减少了30%你将怎样着手完成公司的项目?

    1、对剩余任务做优先级排序。
    2、提高效率:增强人员与任务对关联,责任到人;压缩非必要活动时长(如状态会议)。
    3、与管理层和客户沟通 说明人员减少对项目对影响。
    4、并请求新资源加入,将之与即将退休的老资源一起工作,以便知识传递。尽量将顾问、兼职人员,发展为全职人员。

    21 你的团队主要是由新手组成的,并且进度已经落后。你将做什么?

    很少有项目因延期,而被取消。项目取消主要有:缺少资金、项目不能满足目标、客户不支持。
    1、首先要做的还是培训(磨刀不误砍柴工),线上线下,组员分享或视频录像。(建议知识分享奖励机制,分享课程评分机制)
    2、明确任务,明确任务与人的关联。
    3、提供模型、示例、指南。
    4、一起工作(租用会议室办公)。
    5、多鼓励团队,团建、聚餐增加团队凝聚力、友谊。

    22 你将怎样和与你竞争相同职位的员工相处?

    即是队友,也是对手。
    1、首先是队友:精诚合作,共同提高(有竞争力的人,也是优秀的人,他的竞争力也是你可以学习、加强的地方)。
    2、不要给竞争对手穿小鞋,正常的竞争有利于自己成长(真诚待人,人也会真诚待你)。

    23 如何对待即将退休的员工?

    他们的知识、业务、人员关系是非常宝贵的。
    1、千万不要使绊子,还要给予他们关怀,才有可能多的得到他们的知识、业务上的支持。
    2、退休、离职不一定没有合作的机会。

    24 对一个一贯迟到的员工你会怎么办?

    考虑对团队对影响:影响团队士气,可能会致使整个团队散漫。
    1、找其谈话,了解迟到原因。
    2、强调公司考勤政策(明确团队章程)、以及迟到对团队的影响、对个人评价对影响。

    25 在费用削减的情况下,你将怎样鼓舞士气?

    1、提高团队对项目对认知、了解项目对用户对作用、用了哪些前沿技术。并邀请用户在会议上谈谈对项目的良好印象。
    2、培训,培训有利于提高士气,提高团队对项目、对公司的认同感、归属感。(培训课程太贵,可以找网上免费课程,如B站;亦可有技术分享奖励机制)

    26 你如何雇人?

    1、做岗位描述、岗位要求。
    2、列出团队成员的个性、做事风格。
    3、与人力资源部讨论这些情况,并对候选人甄选,是否有拥有新岗位的必要技能。

    27 你将如何解决团队中的个人冲突?

    1、要求个人私下面对面解决。
    2、私下解决不了,由项目经理、技术主管、小组组长介入;了解任务的轻重缓急,最好说服双方以包容的方式解决;
    其次调节,对冲突点提出第三个解决方案。
    (如果任务紧急,则使用强迫命令一方遵循另一方观点)

    28 你将如何监控/管理顾问?

    1、充分尊重顾问,明确顾问的目标和职责。
    2、坚持做周报,将工作时间与任务完成情况关联起来。

    29 你将如何管理外援?

    1、充分尊重外援,明确外援的目标、职责。
    2、坚持做周报,将工作时间与完成情况关联起来。
    3、如果有外援经理,定期做状态会议,定期做可交付成果检查、验收。

    30 你将如何同一个似乎总是不能按时完成工作的员工一起工作?

    1、与员工了解情况。找到原因。
    2、需要培训则做培训。
    3、如果是管理方面的原因(任务、进度安排不合理、交付日期不明确、其他队员经常打断等),则调整管理方式。

    31 制作原型应该在项目生命周期的那个阶段?

    贯穿整个项目,眼见为实。
    1、校验:规划是否合理,以及开发阶段:软件业务、功能、数据是否符合要求。
    2、极大回避粗制滥造。

    33 在一个维护项目中如何管理和保证质量?

    1、针对历史遗留bug,考虑任务紧急、重要情况,分配给不同的资源。
    2、对于新任务做出任务计划:明确开发流程、交付日期。
    变更需求:
    变更确认:考虑变更是否必要(变更目的,对系统的影响)
    正式记录变更
    起草变更方案,评估变更工作量、优先级
    得到变更控制委员会确认
    变更设计、编码、单体测试、回归测试
    用户确认变更
    产品呈交
    生产

    35 你如何在处理雇员关系,项目管理,文本工作之间分配时间?

    1、注重处理雇员关系,人员是项目的基本。
    2、其次依次是商业目标、公司目标、项目、团队、个人,以及技术、方法的变化。

    36 什么是PM-CMM?

    人员管理成熟度模型。
    随意的:人员管理没有连贯性
    可重复的:在管理方面有一些政策
    明确的:将人员管理和业务结合起来
    可度量的:对人员管理进行目标化
    优化:有计划对不断提高人员水平

    37 生命周期是什么,它的作用是什么?

    生命周期指:项目、产品开始到结束的一系列过程。
    可以明确项目、产品从开发到完成到具体步骤、任务、活动,有利于进度安排成本估算。

    38 描述你的项目计划中应包括的阶段、活动和可交付产品?

    阶段:范围、进度、成本、质量、资源、沟通、风险、采购、干系人等管理计划
    范围:根据:商业论证、协议、项目章程、范围管理计划、需求管理计划、相关方参与计划、组织知识库。
    通过:专家判断、头脑风暴、访谈、标杆对照、原型法,收集需求。投票、多标准决策分析,决定方案。
    制定:需求文件、需求跟踪矩阵、范围基准。
    进度:根据:范围基准
    通过:分解:成工作包、规划包,再分解成具体任务;参数估算、类比估算:任务完成需要时间; 紧前关系绘图法、关键路径法;
    制定:进度、资源需求
    成本:根据:参数估算、类比估算:估算任务成本;质量管理计划;风险登记册、储备估算、成本效益分析
    制定:项目成本
    质量:根据:范围基准、需求说明书、质量测量标准
    制定:质量管理计划

    39 假如某一项目的工期特别紧,而公司现有的资源又比较少,你准备怎么办?

    1、对项目做优先级排序,做出核心可交付成功。与用户一起查验,得到用户支持。
    2、优化项目关键路径
    3、与公司高层沟通,在资源上请求支持(培训或招聘)

    40 一个项目经理所做的工作主要有哪些?一天的工作内容是什么?

    早会、分解任务、分配任务、解决问题,跟进进度,风险预测、风险控制。

    41 项目经理的能力和职能?

    最重要的是沟通能力、组织能力。
    安排合适的人到合适位置,制定完善的项目计划。让项目成员了解各自的目标、任务安排、工作量的安排。
    遇到问题,能够快速的定位问题,分析问题、解决问题。

    42 结合人、成本、功能、质量和进度这五大因素怎样管理好一个项目?

    以人为本,将合适的人安排到合适的位置上。
    一般情况下如果成本超出项目盈利,除非不需要盈利。
    功能:软件项目最基本的要求,功能完美实现方能提高用户对项目的支持。
    质量高:能提高客户对项目的信任。
    好的进度:同样提高客户的满意度。

    43 项目实施有哪些主要阶段,每个阶段应该提交什么成果?

    1、需求分析–需求说明书(双方签字画押)
    2、系统设计–体系结构说明书、数据库设计说明书、界面设计说明书、模块设计说明书、测试要求说明书
    3、实施阶段–开发、测试
    4、交付阶段–客户验收通过
    5、结项阶段–文档交付、项目

    44 如何识别和控制风险?

    根据:管理计划、经验教训知识库、事业环境因素
    通过:专家判断、头脑风暴、假设条件和制约因素分析
    识别风险(人员变动风险、员工休假风险、需求变更风险等、组织调整风险等)

    45 需求变更管理的手段和与客户沟通的手段?

    需求变更:明确变更流程、成立变更委员会。
    客户沟通:简明扼要,如果实际情况需要给客户培训,则安排培训,避免不必要需求。

    46 PMP对你的 人际关系 处理有哪些帮助?

    1 了解项目组织架构,对项目关键干系人有更清晰的认识;(有助于寻找关键干系人)
    2 更加深刻认知干系人的关注点;着重沟通干系人的最关注(有助于寻找沟通重点,不至于让干系人感觉,对牛弹琴)

    47 PMP对你 处理事情 有什么帮助?

    1 对整个项目的架构、流程、生命周期,有更深的认知;(有助于对项目的整体把控)
    2 有更多的解决方案:在项目变更流程中,对变更流程有更多认知;(责任到人,避免不必要变更和扯皮)

    展开全文
  • 全景定位与变更管控有一定的相似性,都是对线上变更的监控与分析,区别在于全景定位主要在风险发生后对变更进行分析(业务在变化,无法保障所有的变更都会接入变更管控),变更管控则主要风险发生前打标,风险发生...

    614a8f8d6417808f72d6cfd03e88fd04.gif

    “本文主要讲述了淘宝客户端的安全生产,即在阿里内外成熟的技术方案的基础上,淘宝客户端是如何来建设自身的安全生产体系,从研发、构建、发布、应急四个阶段再次推动效率和用户体验不断得到升级。”

    安全生产

    首先我们将“客户端安全生产”定义为:为预防客户端研发生命周期过程中发生体验相关的事故,而采取的一系列措施和活动。

    为此淘宝客户端建立了“‘研发、构建、发布、应急’一整套规范化流程及平台”。

    b8bc6c58bfe5ddf617b46fc38d414aaf.png

    图1 安全生产架构图

    淘宝客户端安全生产,主要分四个阶段:研发期、构建期、发布期和应急态,同时沉淀开发过程数据,围绕数据线上线下异常复盘,为提升代码质量、提升开发能力,进一步完善平台做数据支持,从而提升开发的良好研发环境,保障线上用户使用体验。

    1. 研发期:这一阶段主要是指开发同学把需求开发的阶段,往往是单模块的开发,这一阶段主要关注模块自身的质量,这一阶段安全生产平台主要通过需求管理、代码分支管理、单测管理、Code Review、测试请求|审批,一站式的方式为开发同学提供便利;

    2. 构建期:这一阶段主要是指开发同学把已经通过测试的代码,将代码提交到集成区做代码的集成测试,这一阶段安全生产平台主要通过质量卡口、包大小分析、产物校验来确保集成进来的模块是否满足集成标准(重复的资源文件、代码等或高危的隐私API、调试代码等或不合理的组件导出、DEBUG代码等),通过前置风险分析,防止风险代码集成;

    3. 发布期:这一阶段主要在通过测试后发布(灰度、正式)完整的APP、配置变更、活动上线下线,这一阶段需关注APP稳定性数据、性能数据、业务数据与舆情数据(端到云的监控方案),确保发布的APP满足用户的体验要求;

    4. 应急态:前三个阶段主要是规避线上风险线,这一阶段则是在线上APP无法满足用户正常使用时所进入的状态,线上核心指标波动,会触发及时告警,从而通过钉钉快速组建应急小队,对线上问题进行处理,分析问题及问题背后的原因,快速给出解决方案,通过预案回滚、降级处理等手段快速化解线上风险,从而避免风险升级,防止故障产生。

    另外为了确保线上APP的高可用体验,淘宝端架构专门成立了“端侧日常保障”小组,主要从事版本值班、大促保障、应急处理、复盘优化等工作,从日常工作中不断的发现问题、总结思考、优化流程、改进研发环境,不断把部分需要人工介入的流程自动化、数据化、平台化,从而提高“研发、构建、发布、应急”阶段的研发体验和研发效率,最终把人力从重复的、低效的工作中释放出来,通过过程数据不断优化安全生产平台体验,从而保障上层业务健康持续发展。让开发有更多的时间和精力从事更高维度的研发工程,提升开发的成就感。

    研发期

    研发期主要是开发同学开发为主,这里平台提供了代码覆盖率(单测),核心模块中间件的单测代码覆盖率需要满足80%及以上,核心变更需要双人CR(含TL),非核心变更需要技术专家及以上CR。

    构建期

      质量卡口

    随着淘宝业务不断扩张,线上问题时有发生,淘系的场景非常丰富,本地的测试、Review、Monkey、甚至灰度等手段都不能覆盖到所有的场景。但问题一旦到了线上,所花费的成本都急剧增加。

    经过对历史线上问题进行一些分析,发现其中的相当一部分问题,可以通过 “静态代码分析”, “二进制产物分析” 等方法提前发现,那么为什么不能用技术的手段来提前发现问题,阻断它们溜到线上呢。例如:

    1. 同名 Category 方法冲突问题, 导致手淘很多功能异常;

    2. @{} 初始化没判空问题;

    3. oc block持有 c++ this指针导致 User After Free 问题;

    4. objc_msgSend 发送 alloc 导致内存泄露问题;

    5. 一些系统api不再安全,比如vm_remap;

    6. 组件导出;

    7. 线程泄漏;

    8. ......

    这些问题上线后可能就引起很难定位的问题,但是在代码阶段,通过静态分析等手段就可以阻断他们的发生。因此客户端质量卡口平台应运而生,将手淘客户端已有问题扫描工具和规则整合,结合DevSecOps卡口设计的开放卡口接入平台,形成完整的客户端线下问题发现、治理推动和集成卡口的能力,减少线上问题。

    技术方案上,在Android Lint+Spotbugs+Clang Static Analyzer(Android),OCLint(iOS)+Clang Static Analyzer基础上结合淘系具体平台和具体问题进行改进,以满足淘系的技术需求(如扫描线程原生接口使用,辅助淘系整体线程架构迁移)。

      包大小

    包大小是客户端的非常重要的性能指标。从用户视角看,同样的功能和服务,用户倾向于选择安装包比较小的App,可以让用户用更少的流量下载和更新,一定程度提高用户的下载率和更新升级率,对于推广和新增都会有较为重要的影响;从技术视角看,安装包中的每个文件都在瘦身的范围,对不同的文件类型,需要有针对性的瘦身方案,所以瘦身是一个大工程,包含了很多方面的技术。

    Android采用了图片压缩(TinyPng,Webp),重复资源合并、shrinkResource 严格模式、分包、Proguard、ARSC瘦身、下无用代码(代码插桩分析)、无用业务下线、远端so、检测so调试信息。

    iOS采用了图片压缩(TinyPng,Webp)、编译优化(不导出符号、oz、lto)、selectorRef无用资源下线,剔除重复代码、业务下线、共享动态库技术(<iOS9)、Ld链接器压缩。

      产物校检

    产物校验发生在APP发布前的最后一个环节,主要来分析本次发布与上一次发布核心变更存在哪些具体的差异,来确保本次发布的正确性。这一环节主要进行了核心代码变更分析(启动、CrashSDK、监控SDK),需要关注核心代码变更带来的可能的风险;组件导出分析,防止不必要的组件导出,受到外部攻击;签名校验,防止签名出错导致APP无法正常上架;等等。

    发布期

      监控告警

    淘系高度重视手机用户的稳定性和性能,通过高可用的度量指标的建立,稳定性和性能的治理,自动化和数据平台的建设,开发了一套系统化的解决方案及平台EMAS-MOTU,全方位的提升手机淘宝稳定性和性能。

      变更管控

    淘系是一个高频活动运营APP集,我们发现有一些故障是由变更导致的(含活动上线,配置上线等),具有强相关性。因此淘系沉淀了变更管控平台,变更管控平台主要作用是监控分析平台发现的异常数据(Crash、ANR、卡断、泄漏等)与变更的相关性。

    变更管控平台的核心思路是为每一次变更产生一个唯一的变更ID,并在本次变更下发的过程中,将变更ID加入到监控信息的变更ID集里,当监控信息上报时会带上所有的变更ID,服务可以对变更ID进行聚类分析,通过相关性确认相同聚类问题是由哪些变更ID产生的,并对具体的变更留观或回滚,防止风险升级。

    通过精确的变更相关灰度染色数据,管控相关灰度和全量发布,及时卡住异常发布,避免发布引起故障,同时也是提高发布效率的核心手段。

    应急态

      定位

    • 追踪、度量、日志

    随着客户端功能不断细化与完善,模块化、跨团队的协同开发方式已经成为了客户端开发标准的开发方式,模块化、跨团队的协同开发方式的诞生极大提升了客户端交付与部署的效率,但同时可以看到这种模块化、跨团队的架构背后,原先运维与诊断的需求也变得越来越复杂。为了适应客户端日益增长的功能需求,需实现面向用户视角的标准化的DevSecOps诊断与分析系统,包括追踪(Tracing),度量(Metrics),日志(Logging)。

    1. Tracing :用于记录客户端行为范围内的信息,它在单次请求的范围内,处理信息。任何的数据、元数据信息都被绑定到系统中的单个事务上。例如,用户进入页面,到数据渲染的过程。它是我们排查客户端问题的利器;

    2. Metrics :用于记录可聚合的数据。他们具有原子性,每个都是一个逻辑计量单元,或者一个时间段内的柱状图。例如:队列的当前深度可以被定义为一个计量单元,在写入或读取时被更新统计;输入HTTP请求的数量可以被定义为一个计数器,用于简单累加;请求的执行时间可以被定义为一个柱状图,在指定时间片上更新和统计汇总。例如,从客户端发起的网络请求数,与正确收到网络数据的接受。它是我们衡量业务宏观质量的利器;

    3. Logging :用于记录离散的事件。例如,应用程序的调试信息或错误信息。它是我们诊断问题的依据。

    基于追踪(Tracing),度量(Metrics),日志(Logging)的设计原则,淘系借鉴了OpenTracing实现了全日志平台TLog。通过漏斗模型、对比模型通过数据横向对比可以快速发现自身的性能瓶颈,缩小范围,提升排查效率。

    • 全景定位

    淘系是一个高频活动运营APP集,我们发现一些故障是由变更导致的(含活动上线,配置上线等),具有强相关性。因此淘系沉淀了全景定位平台,全景定位平台主要作用是监控分析线上的变更。全景定位平台的核心思路是当线上风险产生时,全景定位平台会主动去收集线上变更,并按时间维度呈现出来,开发可基于全景定位平台快速查看线上变更,定位和排查线上风险与变更的相关性,对潜在风险的变更留观或回滚,直至风险消除。

    全景定位与变更管控有一定的相似性,都是对线上变更的监控与分析,区别在于全景定位主要在风险发生后对变更进行分析(业务在变化,无法保障所有的变更都会接入变更管控),变更管控则主要风险发生前打标,风险发生后对变更进行分析,因此全景定位是变更管控的一种补充与保障

      恢复

    “对代码功能不符合项目预期或代码不够健壮导致App运行时崩溃或异常的线上问题进行恢复”。恢复是淘系应对线上突发问题的重要手段,淘系目前对线上不同的场景采用了不同的恢复策略,目前主要恢复策略有降级、预案、安全模式。

    • 降级

    在淘系复杂生态的环境下,大促期间还是会出现由于各种重资源的业务叠加,导致卡顿,体验明显下降,内存水位暴涨,崩溃率也会随之飙升。因此从2018年开始,尝试开始对重资源、高风险业务,针对不同设备的性能情况进行多维度降级。目的是对用户体验进行分级,实现 “高端设备最炫体验,低端设备流畅优先,紧急问题快速降级”(随着时间的推移,老的设备的软硬件条件,已经无法满足所有新技术、新业务的落地,需要有一定的取舍,从而给每一个设备最佳的用户体验)

    针对不同设备的软硬件不同特性,基于Listwise-SmartScorer模型,淘系对客户端设置了高、中、底三个维度,0-100(0表示设备性能优于市场上主流的0%的设备,100表示设备性能优于市场上主流的100%的设备)的动态的设备评分算法。

    设备评分是个什么?从机器学习的角度来看:它可能是一个分类问题,即设备分为高/中/低三类,我们需要区分这几个类;它可能是一个回归问题,即设备存在一个绝对的分,我们需要去拟合这个分。无论分类还是回归问题,都把设备评分定义为一个绝对的值,而在实际体验中,我们往往说“iPhone X”比“iPhone 8”快,而不是说“iPhone X” 90分,“iPhone 8” 70分,即设备评分是相对的,同时由于设备的损耗,它的评分也是动态的,基于此,我们把设备评分定义为一个排序问题。

    在设备评分的基础上,实现统一降级平台,业务可以通过“高、中、底”或“0-100”选取相应的设备投放自身业务。

    • 预案

    什么是预案?根据评估分析或经验,对潜在的或可能发生的突发事件的类别和影响程度而事先制定的应急处置方案。预案可以降低可预估或不可预估的风险,减少损失,而当下面临大多数的风险,都来自于各类变更,还有阿里最重要的大促场景下,大流量所带来的系统、业务压力。预案有分提前预案和应急预案。

    提前预案:也称定时预案,提前预估大促期间的系统状况与业务状况,为了避免大促的业务峰值影响而进行的缓存预热、机器重启、有限降级、磁盘清理或者业务下线等等,一般对业务无影响或影响可控。

    应急预案针对可能存在的应急情况,如超出预期的异常流量、系统依赖超时及不可用、本系统的非预期不可用等采取的应急手段,一般对业务有损,同时可能会带来客诉,资损等,需要对应的技术、业务等兜底,执行需要慎重。在新增变更中,在Code Review环节,对代码有“可灰度、可监控、可回滚”(稳定性三板斧)要求,即确保代码有应急预案,在线上代码出现风险时,快速回滚。

    预案和降级的区别在于,预案对全部设备采取相同的策略,而降级是对不同的设备采用不同的策略。

    • 安全模式

    恢复场景,(启动阶段)未正常使用网络的崩溃问题。网络未初始化导致配置无法下载发挥作用,于是淘系开发了一个安全模式(在连续触发相同Crash后强制进入“安全模式”--Android轻量级子进程,iOS进入安全模式代码,用来在对程序恢复初始状态(清除历史产生的持久化信息),如有必要会触发配置的下载),为主进程正常启动做必要的保障。如:启动时候因为持久化数据出错,导致APP启动连续闪退,这时安全模式可以发挥巨大作用,弥补配置下发执行前的代码盲区,避免用户只能通过卸载重装APP才能解决问题。

    总结

    客户端安全生产是在淘系较为完善的底层基础设施上建立起来的规范化、自动化、数据化的平台。文中涉及到的技术点是借鉴了阿里内外众多开发、产品、运维等从业人员对历史问题的总结与实现,这里感谢参与安全生产小伙伴的努力与付出,同时也感谢阿里以外的开发、产品、运维对丰富客户端技术、改进用户体验的努力与付出。文中更多的是对APP不同阶段的问题的思考与解问题的思路,希望对大家有帮助。

    参考

    1. 移动研发平台EMAS:https://www.aliyun.com/product/emas

    2. OpenTracing:https://github.com/opentracing

    3. 安全模式:天猫 App 启动保护实践:https://juejin.cn/post/6844903437948157959

    团队介绍

    「商家与消费者平台部 - 终端体验平台」,立足于客户端与平台技术,承担手机淘宝的核心建设与迭代,并致力于移动端、终端及厂商特性的前沿技术探索。业务涵盖 面向消费者端的基础链路、面向商家端的店铺 及小程序体系,是淘系核心技术团队、双11主战部队,及阿里集团移动技术生态的基石团队之一。

    ✿  拓展阅读

    d42f6d17609330528e966ff9094d5f23.png

    2b267a36b4be99618d89ed856375cc50.png

    作者|非台

    编辑|橙子君

    出品|阿里巴巴新零售淘系技术

    4cff6e433a017b5fcbb38e6ab18d5d1d.png

    177bfbd33cb78019399dcb418460da71.png

    展开全文
  • 本文主要是介绍 MOSN 在无人值守变更上的实践以及过程中的一些思考。主要分为 3 个部分:-介绍 MOSN 在规模化运维中遇到的挑战-无人值守上的实践-MOSN 与技术风险方面的思考MO...
  • 文章目录前言一、需求二、资源三、流程四、计划五、沟通六、技术七、外部依赖八、其他总结 ...比如需求阶段,经常会遇到的需求变更问题,产品规划问题,需求不清晰等等,还有人员、流程、计划,沟通等风险。提
  • 并确定是否有必要对成本管理计划进行变更 参考答案:D 解析:书中原话“如果不考虑变更对整体项目目标或计划的影响就开展变更,往往会加剧整体项目风险。” 题目描述是可能出现连环变更,前一变更已获批,但受影响的...
  • 网站变更服务器备案

    2021-08-07 12:06:57
    网站变更服务器备案 内容精选换一换使用华为云备案系统时,全国互联网安全管理服务平台会有一些限制条件,具体限制条件请参见表1。如果您需要使用创建的云服务器搭建一个对外展示的网站或者Web应用程序,请按以下...
  • 需求变更管理

    2021-07-15 15:35:20
    需求变更管理 ​ 需求变更的定义:根据软件工程思想定义,需求说明书一般需要经过论证,如果在开发说明书经过论证以后,需要在原有需求基础上追加和补充新的需求,对原有需求进行修改或削减,都属于需求变更 ​ ...
  • 您仍然可以通过解决公司的变更管理流程来加快软件交付。在本章中,我们将研究我们在公司内部所学的变更管理模式。我们将向您展示什么是有效的,什么是无效的,以及如何利用DevOps原则将变更管理转化为有效的、使能的...
  • 第16章项目变更管理 ...(4)应对风险的紧急计划或回避计划。 (5)项目执行过程与基准要求不一致带来的被动调整。 (6)外部事件。 3.根据变更性质可以分为重大变更、重要变更、一般变更,通过不同审批权...
  • PMP第十一章:项目风险管理

    千次阅读 2021-05-11 22:19:45
    PMP第十一章:项目风险管理 目风险管理 一、项目风险管理核心概念 项目风险: 不确定的事件或条件,一旦发生,就会对一个或多个项目目标造成积极或消极的影响。风险的三要素:风险事件、概率、影响。积极和消极风险...
  • raft中集群成员变更

    2021-02-05 14:19:07
    文章目录raft集群变更再学习单阶段过度的风险分析两阶段过度的完整性分析集群变更时可能存在的其他问题1. 新加入的节点没有日志2. 集群领导人可能需要下线3. 从```C-old```中移除的机器可能会干扰集群 raft集群变更...
  • 整体变更控制流程 提出和接受变更请求; 对变更进行初审; 变更方案论证; CCB对变更进行审查、审批; 发出变更通知并开始实施; 变更实施的监控; 变更效果的评估; 判断发生变更后项目是否已纳入正常轨道; 其中...
  • 风险分类

    千次阅读 2020-12-20 14:24:03
    风险分类控内风险•技术风险•经营风险•管理风险控外风险•资源风险•经济财务风险•政治社会风险•环境风险技术风险•技术风险的种类很多,其主要类型是技术不足风险、技术开发风险、技术保护风险、技术使用风险、...
  • 造成项目变更的原因 1、项目范围描述是管理项目范围的第一步,如果这一步没定义清楚,...每个项目都存在一定的变更风险,项目管理人员不能等着风险找上门,然后手忙脚乱地补救,而应该主动出击,及时根据项目的状态预测
  • 比如研发的功能测试,架构的POC测试/AVL测试,交付的配置验收,优化的灰度变更和方案测试,运营的GNOC模版测试/演练/LANDING测试等等。如何安全、高效和低成本地保证这些环节能够稳定持续运行呢?自动化测试平台 ...
  • 公众号回复:干货,领取价值58元/套IT管理体系文档公众号回复:ITIL教材,领取最新ITIL4中文教材在企业的运维管理过程中,很多时候会有变更产生。这些变更通常来源于基础设施的升级,容量...
  • 生产变更的几点感悟

    2021-03-22 00:10:31
    一直在完善的自动化测试也初见成效:sonar静态代码检查、jar包漏洞扫描、安全风险扫描、单元测试扫描……再加上变更流程的规范:低峰期上线、封禁期等。 生产变更的薄弱环节 这些还不够。个人观点,从变更的稳定性...
  • ITIL-变更管理流程.doc

    2020-12-31 03:06:45
    通过变更管理流程,实现:将变更风险控制在可接受的范围内对用户的影响最小采用合适的控制手段保护其它系统不受影响二、适用范围该流程适用于下列变更:系统硬件和软件的变更生产系统上应用软件的变更网络硬件和软...
  • 如果不考虑变更对整体项目目标或计划的影响就开展变更,往往会加剧整体项目风险。本过程需要在整个项目期间开展。 过程图: 实施整体变更控制过程贯穿项目始终,项目经理对此承担最终责任。变...
  • 变更风险和影响有清晰的认识: 所有的变更都需要经过风险和影响分析,以更好地理解变更并分配必要的资源。风险和影响细节应在计划阶段添加,以便驾驶室对变更有一个清晰的了解,并能给出他们的建议。 建立有效...
  • 文章目录描述目的描述范围定义参考文献角色与职责变更请求状态开始条件任务变更请求REQ-001变更请求REQ-002变更请求REQ-003变更请求REQ-004变更请求REQ-005变更请求REQ-006变更请求REQ-007变更请求REQ-008验证验证...
  • 软考高项之项目变更管理一、变更概念二、变更的原因三、CCB职责四、项目经理职责五、变更申请步骤六、变更其他...④应对风险的紧急计划或回避计划 ⑤项目执行过程与基准要求不一致带来的变动调整 ⑥外部事件 三、CCB
  • 《计算机化系统风险评估报告》由会员分享,可在线阅读,更多相关《计算机化系统风险评估报告(9页珍藏版)》请在人人文库网上搜索。1、计算机化系统风险评估报告内容1.目的52.风险评估小组成员53.范围54.风险评估工具...
  • 基于风险的测试目前已经很热门,它解决了资源紧张,时间紧迫等客观因素给测试工作带来的麻烦。风险级别一般定义为风险可能性X风险严重程度。风险可能性是技术因素,而风险严重程度是产品发布后的社会因素,但这很不...
  • 变更管理 - Change Management 1. 变更管理的目标 变更请求通过结构化的方式被识别、追踪、管理和实现。 2. 变更管理的收益 正确的实施变更管理,所有的对基线项的变更都会管理和控制,各方就 "变更什么" 和 ...
  • 需求变更管理是很多项目的通病。因为对需求变更不重视或管理流程形同虚设,可能造成项目进度延期、成本控制不足、人力资源紧缺,甚至导致整个项目失败。 项目经理要积极面对变更,软件开发需要不断满足用户的需求,...
  • 风险按后果分为纯粹风险和投机风险;②按风险来源或损失产生的原因划分为自然风险和人为风险;③按影响范围分为局部风险和整体风险;④按可预测性分为已知风险、可预测风险和不可预测风险。 为了深入、全面地...
  • 变更在企业运作中是必不可少的,实施变更面临风险,要首先取得高层的认可,让他们知道变更的范围和程度,事前通知用户或是发布流程都是执行变更时的措施,避免出现严重影响用户正常使用的问题发生,比如:邮件服务器...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 85,607
精华内容 34,242
关键字:

变更风险