但是不排除有一些集团公司大的公高正司，他对员工使用的办公电脑进行一个最终他会比如说你下载的流量进行一个监测。同时对你下载的文件或进行一个检测，如果中间有一些流量比较大的这种情况，他就会及时的警示，发出警示以后你可能有些东西就下载不了。
虽然之前一直听说过 ftrace，但从来没将它用在实战中，在一次客户排查问题中，遇到了比较奇怪的现象，一位精通内核的朋友建议使用 ftrace 来定位一下。虽然那一次并没有使用 ftrace，但也让我觉得，后面我们势必要提供 ftrace 相关的工具帮助我们在线上定位问题，所以自己也决定重新学习使用下 ftrace，当然也决定写一系列的相关出来，这里就先简单介绍下 ftrace。
首先我们需要知道，什么是 ftrace？根据 Linux Doc 的介绍，ftrace 是一个 Linux 内部的 trace 工具，能够帮助开发者和系统设计者知道内核当前正在干啥，从而更好的去分析性能问题。
Ftrace 能帮我们分析内核特定的事件，譬如调度，中断等，也能帮我们去追踪动态的内核函数，以及这些函数的调用栈还有栈的使用这些。它也能帮我们去追踪延迟，譬如中断被屏蔽，抢占被禁止的时间，以及唤醒一个进程之后多久开始执行的时间。
可以看到，使用 ftrace 真的能做到对系统内核非常系统的剖析，甚至都能灶隐通过 ftrace 来学习 Linux 内核，不过在更进一步之前，我们需要学会的是 - 如何使用 ftrace。
要使用 ftrace，首先就是需要将系统的 debugfs 或者 tracefs 给挂载到某个地方，幸运的是，几乎所有的 Linux 发行版，都开启了 debugfs/tracefs 的支持，所以我们也没必要去重新编译内核了。
在比较老的内核版本，譬如 CentOS 7 的上面，debugfs 通常被挂载到 /sys/kernel/debug 上面（debug 目录下面有一个 tracing 目录），而比较新的内核，则是将 tracefs 挂载到 /sys/kernel/tracing ，无论是什么，我都喜欢将 tracing 目录直接 link 到 /tracing 。后面都会假设直接进入了 /tracing 目录，后面，我会使用 Ubuntu 16.04 来举例子，内核版本是 4.13 来举例子。
我们使用 ls 来看看目录下面到底有什么：
可以看到，里面有非常多的文件和目录，具体的含义，大家可以去详细的看官方文档的解释，后面只会重点介绍一些文件。
我们可以通过 available_tracers 这个文件知道当前 ftrace 支持哪些插件。
通常用的最多的就是 function 和 function_graph ，当然，如果我们不想 trace 了，可以使用 nop 。我们首先打开 function ：
上面我们将 function 写入到了 current_tracer 来开启 function 的 trace，我通常会在 cat 下 current_tracer 这个文件，主要是防止自己写错了。
然后 ftrace 就开始工作了，会将相关的 trace 信息放到 trace 文件里面，我们直接读取这个文件就能获取相关的信息。
我们可以设置只跟踪特定的 function
当然，如果我们不想 trace schedule 这个函数，也可以这样做：
或者也可隐者以这样做：
Function filter 的设置也支持 *match ， match* ， *match* 这样的正则表达式，譬如我们可以 echo '*lock*' <set_ftrace_notrace 来禁止跟踪带 lock 的函数， set_ftrace_notrace 文件里面这时候就会显示：
相比于 function ， function_graph 能让我们更加详细的去知道内核函数的上下文，我们打开 function_graph ：
我们也可以只跟踪某一个函数的堆栈
上面提到了 function 的 trace，在 ftrace 里面，另外用的多的就是 event 的 trace，我们可以在 events 目录下面看支持那些事件：
上面列出来的都是分组的，我们可以继续深入下去，譬灶辩薯如下面是查看 sched 相关的事件：
对于某一个具体的事件，我们也可以查看：
不知道大家注意到了没有，上述目录里面，都有一个 enable 的文件，我们只需要往里面写入 1，就可以开始 trace 这个事件。譬如下面就开始 trace sched_wakeup 这个事件：
我们也可以 trace sched 里面的所有事件：
当然也可以 trace 所有的事件：
从上面的例子可以看到，其实使用 ftrace 并不是那么方便，我们需要手动的去控制多个文件，但幸运的是，我们有 trace-cmd ，作为 ftrace 的前端， trace-cmd 能够非常方便的让我们进行 ftrace 的 *** 作，譬如我们可以使用 record 命令来 trace sched 事件：
然后使用 report 命令来查看 trace 的数据：
当然，在 report 的时候也可以加入自己的 filter 来过滤数据，譬如下面，我们就过滤出 sched_wakeup 事件并且是 success 为 1 的。
大家可以注意下 success == 1 ，这其实是一个对事件里面 field 进行的表达式运算了，对于不同的事件，我们可以通过查看起 format 来知道它的实际 fields 是怎样的，譬如：
上面只是简单的列出了 ftrace 相关的使用，后续我会在写一些我们或者业界是如何用 ftrace 来解决问题的。另外，我们正在用 ftrace 开发非常多的性能诊断工具，如果你对这一块感兴趣，欢迎联系我 tl@pingcap.com 。
在学习和复习的过程中，我们已经陆续接触到很多近似概念的区别。请大家参照以下整理，并结合PMBOK 相关原文对以下比较容易出考题的概念进行辨析掌握。
1. 关于配置管理活动
o 配置识别。识别与选择配置项，从而为定义与核实产品配置、标记产品和文件、管理变更和明确责任提供基础。
o 配置状态记录。为了能及时提供关于配置项的适当数据，应记录和报告相关信息。此类信息包括已批准的配置识别清单、配置变更请求的状态和已批准的变更的实施状态。
o 配置核实与审计。通过配置核实与配置审计，可以保证项目的配置项组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，从而确保配置文件所规定的功能要求都已实现。
2. 独立型活动、依附型活动和支持型活动
o Discrete Effort 独立型活动：可以被规划、度量并会产生具体结果的活动。（注：独立型活动是挣值管理中为考核工作绩效而采用的三种活动类型之一。）
o Apportioned Effort 依附型活动：其投入需按比例分摊到特定的粗态独立型活动中，其本身无法拆分为独立型活动的活动。（注：依附型活动是挣值管理中为考核工作绩效而采用的三种活动类型之一。）
o Level of Effort (LOE) 支持型活动：一种不产生明确的最终产品，而是按时间流逝来度量的活动。（注：支持型活动是挣值管理中为考核工作绩效而采用的三种活动类型之一。）
3. 总浮动时间和自由浮动时间
o 总浮动时间：总浮动时间是不延误项目完工日期，路径上活动可推迟的时间。它是针对整个路径而言的，其实在正常情况下，总浮动时间也就是关键路径（最长路径）和非关键路径的时差。这里需要注意的是，用七格图画关键路径时，每个活动的七格梁凳指图里都有一个总浮动时间，但其实每个活动里的总浮动时间就是活动上路径的总浮动时间。其实大家认真看可以发现，同一路径上每个活动的总浮动时间都是一样的。在同一路径上只要有一个活动用完总浮动时间，路径上其他活动就不再有总浮动时间了。
o 总浮动时间（Total Float）：在不延误项目完成日期或违反进度制约因素的前提下，某进度活动可以推迟的总时间量（最早开始时间可以推迟的量）。
o 自由浮动时间：是针对单个活动言的，是指在不影响所有紧后活动最早开始日期的前提下（有多个紧后活动动时，就是不影响最早开始时间最小的那小活动），某活动可推迟的时间。PMBOK 中说到自由浮动时间就是指不延误任何紧后活动早开始日期或制约因素的前提下，进度活动可以推迟的时间。所以一般来说公式就是：紧后活动的ES 减去紧前活动的EF，但注意这个只适用于FS 关系。
o 自由浮动时间（Free Float）：在不延误其紧后进度活动最早开始日期的前提橡配下，某进度活动
可以推迟的时间量（最早结束时间可以延后的量）。
o 总时差为负：关键路径上的活动总时差可能为负的原因是由于安排调配不得当所造成的活动非合理性交错现象，有必要调整活动持续时间、逻辑关系等使得活动总时差为零。比如用顺推法所得到的完工日期晚于客户所要求的完工日期。
4. 进度管理计划和项目进度计划
o 进度管理计划是项目管理计划的组成部分。为编制、监督和控制项目进度建立准则和明确活动。其中应包括合适的控制临界值。
A. 控制临界值：可能需要规定偏差临界值，用于监督进度绩效。它是在需要采取某种措施前，允许出现的最大偏差。
B. 项目进度模型制定：需要规定用于制定项目进度模型的进度规划方法论和工具。
C. 准确度：需要规定活动持续时间估算的可接受区间，以及允许的应急储备数量。除此以外还要规定计量单位，组织程序链接，项目进度模型维护，对进度管理计划的变更较多涉及到进度管理方法的变更。
引申：项目 “××管理计划”通常都不涉及具体的管理内容，而是强调相关制度、程序、流程、政策、工具的选择和应用方法。项目进度管理计划和进度计划相类似，范围管理计划和范围基准、成本管理计划和成本基准、质量管理计划和质量测量指标等也有类似的区别。但在各种“××管理计划”中，沟通管理计划是一个例外，其中详细规定了与项目工作相关的沟通对象、沟通需求、沟通频率、沟通方式等详细细节内容。
o 项目进度计划是进度模型的输出，展示活动之间的相互关联，以及计划日期、持续时间、里程碑和所需资源。项目进度计划中至少要包括每个活动的计划开始日期与计划结束日期。可以采用以下一种或多种图形来呈现：
A. 横道图：甘特图，用于向管理层汇报、跟踪活动进度；
B. 里程碑图：又称里程碑进度计划、主进度计划或控制进度计划，用于向客户汇报，了解内外部接口；
C. 项目进度网络图：节点法绘图或逻辑横道图。用于显示活动间逻辑、关键路径。工作分解结构（见5.4 节）为进度管理计划提供了框架，保证了与估算及相应进度计划的协调性。
5. 项进度网络图
o 项目进度网络图： （Project Schedule Network Diagram）：项目进度网络图是表示项目
进度活动之间的逻辑关系（也叫依赖关系）的图形。PMBOK第六版 中文版 page 218 项目进度网络图：包括 “纯逻辑图”，“逻辑横道图”和“时标逻辑图”
o “纯逻辑图”：用节点法绘制，没有时间刻度，纯粹显示活动及其相互关系
o “逻辑横道图”: 项目进度网络图也可以是包含时间刻度的进度网络图图形中有活动日期，通常会同时展示项目网络逻辑和项目关键路径活动.
o “时标逻辑图”:包含时间刻度和表示活动持续时间的横条，以及活动之间的逻辑关系。它用于优化展现活动之间的关系，许多活动都可以按顺序出现在图的同一行中
6. 头脑风暴，名义小组，概念思维导图和亲和图
o 头脑风暴: 是引导技术，群体创新技术, 备选方案生成，群体决策技术，其它质量管理工具（用来定义质量要求）也是信息收集技术。
A.一种用来产生和收集对项目需求与产品需求的多种创意的技术。头脑风暴法本身不包投票或排序，但常与包含该环节的其他群体创新技术一起使用。
B. 一种通用的数据收集和创意激发技术。
C. 通过召集一组团队成员或主题专家，来识别风险、提出创意或问题解决方案。
o 名义小组：对头脑风暴的结果进行排序。
o 概念与思维导图：对头脑风暴的结果进行整合，找出共性与差异。
o 亲和图：对大量创意进行分组。
7. 资源平衡和资源平滑
资源平衡和资源平滑属于资源优化技术（6.5 制定进度计划、6.6 控制进度工具）
o 资源平衡：根据资源限制调整活动时间（资源日历），针对A. 资源特定时间可用、B. 资源有限、C. 过度分配；一般会改变关键路径完工时间。
o 资源平滑：调整活动以满足资源需求不超过资源限制。仅在自由浮动时间和总浮动时间内延迟，针对资源起伏量过大；可能无法实现所有资源的优化，不改变关键路径完工时间。
8. 有效果的沟通和有效率的沟通
o 有效果的沟通是指以正确的形式、在正确的时间把信息提供给正确的受众，并且使信息产生正确的影响。
o 有效率的沟通是指只提供所需要的信息。
注意：项目资源只能用来沟通有利于项目成功的信息，或者那些因缺乏沟通会造成失败的信息。
9. EVM 和EMV
o 挣值管理EVM （Earned Value Management） : 挣值管理（EVM）是把范围、进度和资源绩效综合起来考虑，以评估项目绩效和进展的方法。它是一种常用的项目绩效测量方法。EVM的原理适用于所有行业的所有项目。它针对每个工作包和控制账户，计算并监测以下三个关键指标:计划价值（PV） 挣值（EV）实际成本（AC）。也应该监测实际绩效与基准之间的偏差：进度偏差（SV）成本偏差（CV）进度绩效指数（SPI）成本绩效指数（CPI）
o 预期货币价值EMV (Expected Monetary Value) ：是当某些情况在未来可能发生或不发生时，计算平均结果的一种统计方法（不确定性下的分析）。机会的EMV 通常表示为正值，而威胁的EMV 则表示为负值。EMV 是建立在风险中立的假设之上的，既不避险，也不冒险。
10. 变更日志和问题日志
o 变更日志是一份记录了项目过程中所做变更的综合清单（包括批准和未被批准的变更）。项目文件的一种。变更日志是实施整体变更控制过程输出，再输入于管理相关方参与。相关方就这些变更及其对项目时间、成本和风险等的影响进行沟通。
o 问题日志用于记录和监督与干系人相关的问题的解决项目文件。问题日志是管理相关方参与的输出，再输入与管理项目团队，控制沟通和控制相关方参与。并作为项目文件更新作为输出。另外，在管理沟通时也可以输出问题日志更新。另外，问题日志可以作为识别风险的输入（但不作为独立输入）。引申：日志的类别：变更日志，问题日志，项目日志，书面日志，假设条件日志（定性风险分析 ） Log 日志：对过程或活动实施期间的某些特定事项进行记录、描述或说明的文件。前面常加修饰词，如问题、质量控制、行动或缺陷等。
11. 应急储备和管理储备
o 应急储备可以是一段持续时间/时间缓冲（6.4.2.6），也是预算。可预见 应对“已知—已知”和“已知—未知”风险。包含在进度/成本基准中；管理储备不包括在进度基准中，但属于项目总持续时间的一部分。依据合同条款，使用管理储备可能需要变更进度基准。
o 管理储备特别留出的项目时段，或者是特别留出的项目预算，不可预见 “未知—未知”风险管理储备不包括在进度/成本基准中；管理储备不包括在成本基准中，但属于项目总预算和资金需求的一部分，当动用管理储备资助不可预见的工作时，就要把动用的管理储备增加到成本基准中，从而导致成本基准变更。
12. 风险应对措施/应对策略
o Response 应对措施 在识别风险过程中，有时可以识别出风险的潜在应对措施。并随着定性，定量（如果有的话）风险分析过程做调整，并在规划风险应对过程中将选择和商定的风险应对措施应该列入风险登记册。规划风险应对节将分别讨论威胁和机会的应对措施。
o Contingent Response Strategies 应急应对策略：事先制定的，在某个特定触发条件发生时，可以启动的应对措施。采用这一技术制定的风险应对方案，通常称为应急计划或d回计划（contingency plans or fallback plans），其中包括已识别的、用于启动计划的触发事件。
o Contingency Plan 应急计划 通过风险应急应对策略制定出的风险应对措施。针对“已知-未知“风险。动用应急储备。
o Workaround 权变措施：在未事先制定应对措施或事先制定的应对措施无效时，针对已发生的威胁而采取的应对措施。是针对以往未曾识别或被动接受的、目前正在发生的风险而采取的、未经事先计划的应对措施。 针对”未知-未知”风险。动用管理储备。
o Fallback Plan d回计划：包含一组备用的行动和任务，以便在主计划因问题、风险或其他原因而废弃时采用。也就是说在风险发生并且主要应对措施无效时使用。
13. 合同类型
关于合同类型的选择买方风险（威胁和机会）角度：总价合同＜工料合同＜成本合同
o 总价合同：如果工作范围明确，项目的设计已具备充分的细节——总价合同（对买方的风险最小）
o 工料合同：如果工作性质清楚，但工作量不确定且不复杂，需要快速处理——工料；（资源、雇人）
o 成本补偿：如果工作范围不清楚，无法明确定义——成本补偿
14. 预防措施、纠正措施、缺陷补救和更新
o 纠正措施。为使项目工作绩效重新与项目管理计划一致而进行的有目的的活动。旨在维持一个有效过程的自然稳定性。纠正措施旨在维持一个有效过程的自然稳定性。
o 预防措施。为确保项目工作的未来绩效符合项目管理计划而进行的有目的的活动。
o 缺陷补救。为了修正不一致的产品或产品组件而进行的有目的的活动。
o 更新。对正式受控的项目文件或计划等进行的变更，以反映修改或增加的意见或内容。
A. 推荐的纠正措施，包括为使项目工作绩效重新与项目管理计划保持一致而提出的变更；推荐的纠正措施。为了使项目工作绩效重新符合项目管理计划而开展的活动，包括应急计划和权变措施。后者是针对以往未曾识别或被动接受的、目前正在发生的风险而采取的、未经事先计划的应对措施。
B. 推荐的预防措施，这些措施可以降低在未来产生不良项目绩效的可能性。
15. 配置管理计划，配置管理系统，配置管理知识库
o 配置管理计划：用来明确如何开展配置管理。配置管理计划。配置管理计划定义哪些是配置项，哪些配置项需要正式变更控制，以及针对这些配置项的变更控制过程。
o 配置管理系统Configuration Management System：整个项目管理系统的一个子系统。它由一系列正式的书面程序组成，用于对以下工作提供技术和管理方面的指导与监督：识别并记录产品、成果、服务或部件的功能特征和物理特征；控制对上述特征的任何变更；记录并报告每项变更及其实施情况；支持对产品、成果或部件的审查，以确保其符合要求。该系统包括文件和跟踪系统，并明确了为核准和控制变更所需的审批级别。
o 配置管理知识库：包括执行组织的所有标准、政策、程序和任何项目文件的各种版本与基准。
16. Product metrics 产品测量指标 和 Quality Metrics 质量测量指标
o 产品测量指标：列举在需求管理计划里的产品测量指标。
o 质量测量指标：质量测量指标专用于描述项目或产品属性，以及控制质量过程将如何对属性进行测量。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）