精华内容
下载资源
问答
  • 超全整理!Python数据分析知识体系

    千次阅读 2017-05-06 19:16:43
    自从1991年诞生以来,Python现在已经成为最受...在数据分析和交互、探索性计算以及数据可视化方面,Python将不可避免地接近于其他开源和商业领域的特定编程语言/工具,如R、matlab、SAS、stata等。 下面是笔者在学习

    自从1991年诞生以来,Python现在已经成为最受欢迎的动态编程语言之一,Python最大的特点是拥有一个巨大而活跃的科学计算社区。进入21世纪以来,在行业应用和学术研究中采用Python进行科学计算的势头越来越猛。
    在数据分析和交互、探索性计算以及数据可视化方面,Python将不可避免地接近于其他开源和商业领域的特定编程语言/工具,如R、matlab、SAS、stata等。
    下面是笔者在学习用Python进行数据分析过程中对Python数据分析的知识体系进行梳理,能够帮助大家在学习过程中对Python数据分析有个整体把握。

    Python数据分析知识体系

    展开全文
  • 很多人都看过不同类型的书,也接触过很多有关...针对前端不同渠道进行数据埋点,然后根据不同渠道的采集多维数据,也就是做大数据的第一步,没有全量数据,何谈大数据分析; 第二步,基于采集回来的多维度数据,...

    很多人都看过不同类型的书,也接触过很多有关大数据方面的文章,但都是很零散不成系统,对自己也没有起到多大的作用,所以作者第一时间,带大家从整体体系思路上,了解大数据产品设计架构和技术策略。

    大数据产品,从系统性和体系思路上来做,主要分为五步:

    1. 针对前端不同渠道进行数据埋点,然后根据不同渠道的采集多维数据,也就是做大数据的第一步,没有全量数据,何谈大数据分析;
    2. 第二步,基于采集回来的多维度数据,采用ETL对其各类数据进行结构化处理及加载;
    3. 然后第三步,对于ETL处理后的标准化结构数据,建立数据存储管理子系统,归集到底层数据仓库,这一步很关键,基于数据仓库,对其内部数据分解成基础的同类数据集市;
    4. 然后基于归集分解的不同数据集市,利用各类R函数包对其数据集进行数据建模和各类算法设计,里面算法是需要自己设计,个别算法可以用R函数,这个过程产品和运营参与最多;这一步做好了,也是很多公司用户画像系统的底层。
    5. 最后根据建立的各类数据模型及算法,结合前端不同渠道不同业务特征,根据渠道触点自动匹配后端模型自动展现用户个性化产品和服务。

    腾讯数据总监教学:仅用5步,即可从0-1构建大数据知识体系

     

    建立系统性数据采集指标体系

    建立数据采集分析指标体系是形成营销数据集市的基础,也是营销数据集市覆盖用户行为数据广度和深度的前提。

    数据采集分析体系要包含用户全活动行为触点数据,用户结构化相关数据及非结构化相关数据,根据数据分析指标体系才能归类汇总形成筛选用户条件的属性和属性值,也是发现新的营销事件的基础。

    构建营销数据指标分析模型,完善升级数据指标采集,依托用户全流程行为触点,建立用户行为消费特征和个体属性,从用户行为分析、商业经营数据分析、营销数据分析三个维度,形成用户行为特征分析模型。用户维度数据指标是不同维度分析要素与用户全生命周期轨迹各触点的二维交叉得出。

    目前做大数据平台的公司,大多数采集的数据指标和输出的可视化报表,都存在几个关键问题:

    1. 采集的数据都是以渠道、日期、地区统计,无法定位到具体每个用户;
    2. 计算统计出的数据都是规模数据,针对规模数据进行挖掘分析,无法支持;
    3. 数据无法支撑系统做用户获客、留存、营销推送使用;

    所以,要使系统采集的数据指标能够支持平台前端的个性化行为分析,必须围绕用户为主线来进行画像设计,在初期可视化报表成果基础上,将统计出来的不同规模数据,细分定位到每个用户,使每个数据都有一个用户归属。

    将分散无序的统计数据,在依据用户来衔接起来,在现有产品界面上,每个统计数据都增加一个标签,点击标签,可以展示对应每个用户的行为数据,同时可以链接到其他统计数据页面。

    由此可以推导出,以用户为主线来建立数据采集指标维度:用户身份信息、用户社会生活信息、用户资产信息、用户行为偏好信息、用户购物偏好、用户价值、用户反馈、用户忠诚度等多个维度,依据建立的采集数据维度,可以细分到数据指标或数据属性项。

    ① 用户身份信息维度

    性别,年龄,星座,居住城市,活跃区域,证件信息,学历,收入,健康等。

    ② 用户社会生活信息维度

    行业,职业,是否有孩子,孩子年龄,车辆,住房性质,通信情况,流量使用情况……

    ③ 用户行为偏好信息

    是否有网购行为,风险敏感度,价格敏感度,品牌敏感度,收益敏感度,产品偏好,渠道偏好……

    ④ 用户购物偏好信息

    品类偏好,产品偏好,购物频次,浏览偏好,营销广告喜好,购物时间偏好,单次购物最高金额……

    ⑤ 用户反馈信息维度

    用户参与的活动,参与的讨论,收藏的产品,购买过的商品,推荐过的产品,评论过的产品……

    腾讯数据总监教学:仅用5步,即可从0-1构建大数据知识体系

     

    基于采集回来的多维度数据,采用ETL对其各类数据进行结构化处理及加载

    • 数据补缺:对空数据、缺失数据进行数据补缺操作,无法处理的做标记。
    • 数据替换:对无效数据进行数据的替换。
    • 格式规范化:将源数据抽取的数据格式转换成为便于进入仓库处理的目标数据格式。
    • 主外键约束:通过建立主外键约束,对非法数据进行数据替换或导出到错误文件重新处理。
    • 数据合并:多用表关联实现(每个字段加索引,保证关联查询的效率)
    • 数据拆分:按一定规则进行数据拆分
    • 行列互换、排序/修改序号、去除重复记录

    数据处理层 由 Hadoop集群 组成 , Hadoop集群从数据采集源读取业务数据,通过并行计算完成业务数据的处理逻辑,将数据筛选归并形成目标数据。

    数据建模、用户画像及特征算法

    提取与营销相关的客户、产品、服务数据,采用聚类分析和关联分析方法搭建数据模型,通过用户规则属性配置、规则模板配置、用户画像打标签,形成用户数据规则集,利用规则引擎实现营销推送和条件触发的实时营销推送,同步到前端渠道交互平台来执行营销规则,并将营销执行效果信息实时返回到大数据系统。

    腾讯数据总监教学:仅用5步,即可从0-1构建大数据知识体系

     

    根据前端用户不同个性化行为,自动匹配规则并触发推送内容

    根据用户全流程活动行为轨迹,分析用户与线上渠道与线下渠道接触的所有行为触点,对营销用户打标签,形成用户行为画像。

    基于用户画像提炼汇总营销筛选规则属性及属性值,最终形成细分用户群体的条件。每个用户属性对应多个不同属性值,属性值可根据不同活动个性化进行配置,支持用户黑白名单的管理功能。

    可以预先配置好基于不同用户身份特性的活动规则和模型,当前端用户来触发配置好的营销事件,数据系统根据匹配度最高的原则来实时自动推送营销规则,并通过实时推送功能来配置推送的活动内容、优惠信息和产品信息等,同时汇总前端反馈回的效果数据,对推送规则和内容进行优化调整。

     

    腾讯数据总监教学:仅用5步,即可从0-1构建大数据知识体系

    FineBI做的数据可视化

    大数据系统结合客户营销系统在现有用户画像、用户属性打标签、客户和营销规则配置推送、同类型用户特性归集分库模型基础上,未来将逐步扩展机器深度学习功能,通过系统自动搜集分析前端用户实时变化数据,依据建设的机器深度学习函数模型,自动计算匹配用户需求的函数参数和对应规则,营销系统根据计算出的规则模型,实时自动推送高度匹配的营销活动和内容信息。

    腾讯数据总监教学:仅用5步,即可从0-1构建大数据知识体系

     

    机器自学习模型算法是未来大数据系统深度学习的核心,通过系统大量采样训练,多次数据验证和参数调整,才能最终确定相对精准的函数因子和参数值,从而可以根据前端用户产生的实时行为数据,系统可自动计算对应的营销规则和推荐模型。

    大数据系统在深度自学习外,未来将通过逐步开放合作理念,对接外部第三方平台,扩展客户数据范围和行为触点,尽可能覆盖用户线上线下全生命周期行为轨迹,掌握用户各行为触点数据,扩大客户数据集市和事件库,才能深层次挖掘客户全方位需求,结合机器自学习功能,从根本上提升产品销售能力和客户全方位体验感知。

    展开全文
  • 敏捷开发知识体系

    千次阅读 2017-03-28 08:27:20
    敏捷开发知识体系整体框架 敏捷开发工程实践 项目管理 迭代开发风险价值生命周期多级项目规划完整团队每日站立会议任务板燃尽图 需求管理 需求订单业务流程草图用例驱动开发用户故事 架构 演进...

    敏捷开发知识体系整体框架

    敏捷开发工程实践

    项目管理

    • 迭代开发
    • 风险价值生命周期
    • 多级项目规划
    • 完整团队
    • 每日站立会议
    • 任务板
    • 燃尽图

    需求管理

    • 需求订单
    • 业务流程草图
    • 用例驱动开发
    • 用户故事

    架构

    • 演进的架构
    • 演进的设计
    • 基于组件的架构设计

    开发

    • 结对编程
    • 测试驱动开发
    • 重构
    • 代码规范

    测试

    • 单元测试
    • 并行测试
    • 测试管理

    变更管理

    • 持续集成
    • 自动构建
    • 团队变更管理

    敏捷开发管理实践描述

    • 定义和特征说明
    • 主要角色
    • 主要活动和最佳实践
    • 主要输入输出
    • 工作流程

    敏捷开发工程实践描述

    • 定义和特征说明
    • 应用说明
    • 案例说明

    敏捷开发核心价值观和原则

    敏捷软件开发宣言

    个体和互动 高于 流程和文档
    工作的软件 高于 详尽的文档
    客户合作 高于 合同谈判
    响应变化 高于 遵循计划
    也就是说, 尽管右项有其价值, 我们更重视左项的价值.
    • 1
    • 2
    • 3
    • 4
    • 5
    • 1
    • 2
    • 3
    • 4
    • 5

    敏捷软件开发的核心价值观

    敏捷开发的核心理念就是以最简单有效的方式快速打成目标, 并在这个过程中及时地响应外界的变化, 做出迅速的调整.

    核心价值观

    • 以人为本
    • 目标导向
    • 客户为先
    • 拥抱变化

    敏捷开发的原则

    • 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
    • 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
    • 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
    • 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
    • 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
    • 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
    • 可工作的软件是进度的首要度量标准。
    • 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
    • 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
    • 以简洁为本,它是极力减少不必要工作量的艺术。
    • 最好的架构、需求和设计出自自组织团队。
    • 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

    敏捷开发管理实践

    Scrum

    Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。

    Scrum中的角色

    “猪”角色

    • 产品负责人(Product Owner) 
      • 通常由市场部门的人担任
    • 敏捷教练 (Scrum Master) 
      • 通常由开发组组长担任
    • 开发团队 (Scrum Team) 
      • 包括开发,需求,测试

    “鸡”角色

    • 用户 
      • 软件是为了某些人而创建!就像“假如森林里有一棵树倒下了,但没有人听到,那么它算发出了声音吗”,“假如软件没有被使用,那么它算是被开发出来了么?”
    • 利益所有者 (客户,提供商) 
      • 影响项目成功的人, 但只直接参与冲刺评审过程。
    • 管理者 
      • 为产品开发团体架起环境的那个人

    主要活动和最佳实践

    • 迭代式软件开发
    • 两层项目规划 (Two-Level Project Planning)
    • 整体团队协作 (Whole Team)
    • 持续集成
    • 冲刺规划会议 (Sprint Plan Meeting)
    • 每日站立会议 (Sprint Daily Meeting)
    • 冲刺复审会议 (Sprint Review Meeting)
    • 冲刺回顾会议 (Retrospective Meeting)

    scrum方法中得主要活动和交付件

    主要输入输出

    • 产品订单(Product Backlog)
    • 冲刺订单(Spring Backlog)
    • 燃尽图(Burndown Chart)
    • 新的功能增量

    工作流程

    scrum方法全景图

    项目管理过程

    • 在Scrum项目管理过程中产品负责人获取项目投资, 并对整个产品的成功负责.
    • 产品负责人协调个中利益干系人, 确定产品订单中初始的需求清单及其优先级, 完成项目商业价值分析和项目整体规划, 并任命合适的敏捷教练开展项目工作.

    项目开发过程

    在Scrum软件开发过程中, 每个冲刺就是较短的迭代, 通常为2~4周.

    • 在每个冲刺开始时, 产品负责人和敏捷教练通过召开冲刺规划会议和”两层项目规划”的最佳实践, 制定冲刺订单(类似迭代计划)
    • 产品负责人明确在本次冲刺中实现的需求清单, 响应的工作任务和负责人.
    • 在每个冲刺迭代中, 团队强调应用”整体团队协作”的最佳实践, 通过保持可持续发展的工作节奏和每日站立会议, 实现团队的自组织, 自适应和自管理, 高效完成冲刺工作.
    • 在每个冲刺结束时, 团队都会召开冲刺复审会议, 团队成员会在会上分别展示他们开发出的软件(或其他有价值的产品), 并从产品负责人和其他利益关系人那里, 得到反馈信息.
    • 在冲刺复审会议之后, 团队会自觉招开冲刺回顾会议, 回顾整个项目过程, 讨论哪些方法做的好, 哪些方面可以改进, 实现软件交付过程的持续, 自发的改进.

    XP

    OpenUp

    Lean

    敏捷开发工程实践

    迭代式开发

    敏捷迭代开发是指每次按照相同的开发方式短期的开发软件的部分, 或前期开发并不详尽的软件, 每次开发结束获得可以运行的软件, 以供各方干系人观测, 获得反馈, 根据反馈适应性的进行后续开发, 经过发福多次开发, 逐步增加软件部分, 逐步补充完善软件, 最终开发得到最后的软件. 每次反复开开发叫一次迭代, 在Scrum中成为Sprint, 中文常译为”冲刺”.

    持续集成

    持续集成(Continuous integration)是指当代码提交后, 马上启动自动编译, 自动部署金额自动化测试来快速验证软件, 从而尽快的发现集成错误.

    多级项目规划

    多级项目/产品规划, 在软件开发领域, 是指以迭代开发为基础, 形成多层次的, 逐步细化的项目或产品计划. 这些层层相关的项目/产品规划包括:

    • 项目/产品愿景
    • 项目/产品路线图
    • 版本发布计划
    • 迭代计划
    • 每日实现

    项目/产品愿景

    在计划阶段, 首先, 项目stakeholder, 项目/产品负责人将参与并组成工作组, 他们负责阐述项目的重要性, 给出项目成功失败的关键标准以及项目整体层面”完成”的定义; 在过程中, 可以利用形成项目愿景的一些个工具, 包括愿景盒子(Vison Box), 业务收益矩阵(Business Benefits Matrix), 项目范围矩阵(Scope Matrix), 滑动器(Slider), 成本收益矩阵(Cost/Benefit Matrix)等; 最后, 项目愿景需要使用尽量简要的文档固定下来, 并保证项目团队成员都能了解.该文档需要包括:

    • 当前的问题
    • 机会描述和理由(描述项目的重要性)
    • 项目的价值
    • 项目如何和组织的战略目标达成一致
    • 解决方案综述
    • 项目包含的关键功能
    • 项目必须服从的技术和约束条件
    • 项目范围
    • 项目的关键时间线
    • 项目收益分析
    • 项目和其他项目的依赖性
    • 项目的相关风险以及如何消除

    项目/产品路线图

    主要描述为了达到产品愿景而需要交付的关键功能和特性, 这些特性基本处于Epic和特性层面, 不包裹用户故事(User Story). 它从时间的维度来表述对愿景的支持和实现. 它从时间维度来表达对愿景的支持和实现. 当项目/产品需要发布多个版本时, 项目线路图就非常重要, 否则, 它和发布计划相同, 项目/产品线路图由项目负责人和项目经理维护, 并保持更新. 通常, 会形成路线图问题或幻灯片, 使用大图标显示重要的里程碑, 包含的功能和发布日期等, 让所有项目/产品相关人员都清楚产品各个组件的可能发布日程.

    版本发布计划

    版本发布计划由团队成员和项目/产品负责人共同制定, 并通过版本发布计划会议讨论通过. 它包括了当前版本需要交付的, 达成一致的关键功能, 并经过优先级排序, 可以包含EPIC和User Story. 版本发布计划中常使用的概念包括:故事点, 迭代团队速率和优先级排序. 通常, 项目/产品负责人提出本次发布的目标, 团队成员根据目标和功能特性的重要性对故事进行排序, 并依据团队速率觉得本次发布需要包含的故事点. 前几次版本发布使用估算值, 其准确性随着项目/产品的时间持续而逐步精确. 版本发布计划是剧本适应性可调整的计划, 会随着项目演进而改变.

    迭代计划

    迭代计划是对版本发布计划的再次细化, 同样由团队成员和项目/产品负责人共同制定, 并听过迭代计划会议讨论通过. 迭代会议负责两件事情:

    • 根据当前状态确定是否需要对版本计划做出更新
    • 为当前的迭代计划制定迭代计划

    迭代计划中常使用的概念包括: 拆分Epic和User Story, 任务, 任务估算. 在迭代会议上, 成员首先根据当前的项目变化对发布计划进行更新, 然后根据更新后的, 重新排序过的故事制定当前迭代需要完成的故事, 并对这些故事进行详细的任务拆分. 成员在认领完任务后, 会对任务的实现时间做出估算, 估算值需要具体到这些估算信息可以方便任何成员追踪任务的进度.

    每日实现

    没事实现是团队成员完成任务的具体过程, 它依据任务估算值并根据任务最终实现情况更新该值. 在敏捷方法中, 使用每日站会议来报告进度. 通过15分钟的站立形式, 团队成员报告故事或者任务的完成,未完成状态, 而解决层面的问题则在会议之后处理.

    完整团队

    Scrum团队必须具备的三个完整性:

    团队职责完整性

    产品负责人(Product Owner)

    • 确定产品的功能。
    • 决定发布的日期和发布内容。
    • 为产品的收益(profitability of the product)负责。
    • 根据市场价值确定功能优先级。
    • 在30天内调整功能和调整功能优先级。
    • 接受或拒绝接受开发团队的工作成果

    敏捷教练 (Scrum Master)

    • 负责监督整个Scrum项目进程, 调整开发计划
    • 保证团队资源完全可被利用并且全部是高产出的。
    • 保证各个角色及职责的良好协作。
    • 解决团队开发中的障碍。
    • 做为团队和外部的接口,屏蔽外界对团队成员的干扰。
    • 保证开发过程按计划进行,组织 Daily Scrum, Sprint Review and Sprint Planning meetings。
    • 需要知道什么任务已经完成,哪些任务已经开始,哪些新的任务已发现,和哪些估计可能已经发生变化. 根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图
    • 需要找出阻碍Scrum的障碍和依赖, 根据优先级指定计划解决这些障碍
    • 个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清,或通过内部的沟通解决,或向管理层和HR寻求帮助解决
    • Scrum Master需要知道什么任务已经完成,哪些任务已经开始,哪些新的任务已发现,和哪些估计可能已经发生变化。Scrum Master需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的Burndown Chart。 Scrum Master还必须仔细考虑进展中的开放任务数,进展中的工作需要得到最小化,以实现精益生产率的收益。
    • Scrum Master需要找出阻碍Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决,有些则要团队之间的协调,还有的要管理层的介入来解决.

    开发团队 (Scrum Team)

    • 具有不同特长的团队成员,人数控制在5-7个左右, 跨职能, 包括开发, 需求, 测试
    • 弱化分工, 每个人都参与设计, 开发与测试
    • 确定Sprint目标和具体说明的工作成果。
    • 在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
    • 向Product Owner演示产品功能。

    团队素质完整性

    • 要具备很强的集体协作精神.
    • 要具备良好的沟通能力
    • 必须能积极主动的接受新的事物, 要具备创新能力
    • 要具备极强的自我管理能力和积极主动的精神

    沟通的完整性

    • Sprint启动会
    • 每日站立会议
    • Sprint回顾会

    案例

    验收测试驱动开发ATDD

    TDD 只是开发人员的职责,通过单元测试用例来驱动功能代码的实现。ATDD在准备实施一个功能或特性之前,首先团队需要定义出期望的质量标准和验收细则,以明确而且达成共识的验收测试计划(包含一系列测试场景)来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员,强调如何实现系统以及如何检验。

    • 挑选用户故事
    • 为故事写测试
    • 实现测试
    • 实现故事

    结对编程

    结对编程可以看做是一种敏捷化的Code Review

    新结对编程

    两位程序员新成结对小组, 每人一台电脑, 坐在临近的工位上, 两人合作完成一组功能(可以是两个或多个独立的模块)的设计, 代码实现. 但对已某一个模块来说设计和代码是分开的, 一个人负责设计, 另一个人负责写代码, 对于其他模块则反之.

    确定冲刺计划

    定义和说明

    • 目的: ST和PO共同决定在接下来的冲刺周期内的目标以及那些功能和任务需求要完成
    • 主要角色: ST, PO, SM
    • 主要输入: Product backlog, 团队的能力
    • 主要输出: Sprint Backlog

    冲刺会议分两个部分 
    1. 解决本次冲刺要完成哪些需求 
    2. 解决这些选择的需求要如何被完成

    案例

    故事点估算

    故事点是表述一个用户故事, 一项功能或一件工作的整体大小的一种度量单位. 数值本身不重要, 重要的是这些故事之间对比体现相对大小.

    计划扑克

    • 开始时, 美人得到一张扑克, 上面有任务点(?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, 无穷).?代表无法估算, 无穷代表故事太大
    • 开始对故事进行估算, 先由PO介绍这个故事的描述. 接着澄清问题
    • 每一个组员从扑克中挑选可以代表这个故事的卡片, 集体亮牌
    • 最高分和最低分的组员像团队做出解释
    • 全组成员自由讨论几分钟
    • 重新打分, 直到全组统一.

    敏捷估算2.0(Agile Estmating 2.0)

    • PO像团队成员介绍每一个用户故事, 确保所有需求相关的问题都在做估算前得到解决
    • 整个团队参与游戏: 一次由一人将一个故事卡片放在合适的位置, 规模小的在左,规模大的在右, 一样大的竖排. 轮流移动故事卡片, 直到整个团队都认同白板上故事卡的排序为止.
    • 团队将故事点(Story Point)分配给每个故事.

    需求订单(Product Backlog)

    记录用户需求的列表, 包括产品所有需要的特征.

    • 每一项包含了需求标题, 描述, 重要性, 故事点(或其他表示大小的数字)
    • 需求订单式开放的, 团队每个成员都可以编写和维护
    • 在整个项目开放生命周期内, 需求订单需要不断维护, 管理与跟踪需求变化

    燃尽图

    在项目完成之前, 对需要完成的工作的一种可视化表示. 燃烧故事点.每天更新一次

    • 具备可视性
    • 具备风险预估, 提醒团队目前完成情况
    • 具备可估量, 直接显示当前还需要的时间.

    燃尽图常见问题

    每日站立会议(Daily Scrum)

    每日站立会议旨在让团队统一目标, 协调内部问题的解决, 绝非进度汇报.一般不超过15分钟.

    • 我们上次开会后你都干了什么
    • 在我们下次开会之前你要做什么
    • 每个你负责的、正在做的任务还剩下多少时间
    • 你的工作被阻碍了吗

    任务板(Task board)

    • 为项目团队提供一个便利的工具用于管理他们的工作
    • 是团队成员对本冲刺的工作一目了然

    任务板通常设立与项目团队日常工作的公共空间的一面墙上. 任务板上得信息包括该冲洗计划完成的用户故事和相应的任务, 分别卸载卡片上, 按照一定的方式贴在任务板上(To Do, In Progress, Done). 团队成员通过调整任务卡得位置和上面的信息反映任务的执行情况.

    用户故事卡

    每张卡片记录一条用户故事, 故事点.

    任务卡

    每个用户故事卡片通对应的多个任务卡. 每张卡片记录一条任务, 到目前为止完成该任务所需的工作量(小时).随着进展试试更新.

    任务板的使用

    用户故事

    作为<某个角色>, 我希望<实现何种功能>, 以便<带来何种价值>.

    如: 作为一个用户, 我希望在每次退出系统前得到是否保存的提示, 以便所有内容都被成功存储了.

    测试驱动开发(TDD)

    先开发测试用例, 然后再开发代码

    展开全文
  • 运维监控知识体系

    千次阅读 2019-02-04 12:58:57
    当然对监控不是很明白的朋友们,看了以下文章可能会对监控整个体系有比较深刻的认识。 0 监控目标 我们先来了解什么是监控,监控的重要性以及监控的目标,当然每个人所在的行业不同、公司不同、业务不...

    监控是整个运维乃至整个产品生命周期中最重要的一环,事前及时预警发现故障,事后提供详实的数据用于追查定位问题。 
    目前业界有很多不错的开源产品可供选择。选择一款开源的监控系统,是一个省时省力,效率最高的方案。当然对监控不是很明白的朋友们,看了以下文章可能会对监控整个体系有比较深刻的认识。

    0 监控目标

    我们先来了解什么是监控,监控的重要性以及监控的目标,当然每个人所在的行业不同、公司不同、业务不同、岗位不同、对监控的理解也不同,但是我们需要注意,监控是需要站在公司的业务角度去考虑,而不是针对某个监控技术的使用。 

    监控目标

     

    监控目标

    • 1.对系统不间断实时监控:实际上是对系统不间断的实时监控(这就是监控)
    • 2.实时反馈系统当前状态:我们监控某个硬件、或者某个系统,都是需要能实时看到当前系统的状态,是正常、异常、或者故障
    • 3.保证服务可靠性安全性:我们监控的目的就是要保证系统、服务、业务正常运行
    • 4.保证业务持续稳定运行:如果我们的监控做得很完善,即使出现故障,能第一时间接收到故障报警,在第一时间处理解决,从而保证业务持续性的稳定运行。

     

    1 监控方法

    既然我们了解到了监控的重要性、以及监控的目的,那么下面我们需要了解下监控有哪些方法。

     

    监控方法

     

    监控方法

    1.了解监控对象:我们要监控的对象你是否了解呢?比如CPU到底是如何工作的? 
    2.性能基准指标:我们要监控这个东西的什么属性?比如CPU的使用率、负载、用户态、内核态、上下文切换。 
    3.报警阈值定义:怎么样才算是故障,要报警呢?比如CPU的负载到底多少算高,用户态、内核态分别跑多少算高? 
    4.故障处理流程:收到了故障报警,那么我们怎么处理呢?有什么更高效的处理流程吗?

     

    2 监控核心

    我们了解了监控的方法、监控对象、性能指标、报警阈值定义、以及故障处理流程几步骤,当然我们更需要知道监控的核心是什么? 

    监控核心

     

    监控核心

    1.发现问题:当系统发生故障报警,我们会收到故障报警的信息 
    2.定位问题:故障邮件一般都会写某某主机故障、具体故障的内容,我们需要对报警内容进行分析,比如一台服务器连不上:我们就需要考虑是网络问题、还是负载太高导致长时间无法连接,又或者某开发触发了防火墙禁止的相关策略等等,我们就需要去分析故障具体原因。 
    3.解决问题:当然我们了解到故障的原因后,就需要通过故障解决的优先级去解决该故障。 
    4.总结问题:当我们解决完重大故障后,需要对故障原因以及防范进行总结归纳,避免以后重复出现。

     

    3 监控工具

    下面我们需要选择一款合适公司业务的监控工具进行监控,这里我对监控工具进行了简单的分类 
    监控工具

     

    监控工具

    老牌监控: 
    1、MRTG(Multi Route Trffic Grapher)是一套可用来绘制网络流量图的软件,由瑞士奥尔滕的Tobias Oetiker与Dave Rand所开发,以GPL授权。 
    MRTG最好的版本是1995年推出的,用perl语言写成,可跨平台使用,数据采集用SNMP协议,MRTG将收集到的数据通过Web页面以GIF或者PNG格式绘制出图像。

    2、Grnglia是一个跨平台的、可扩展的、高性能的分布式监控系统,如集群和网格。它基于分层设计,使用广泛的技术,用RRDtool存储数据。具有可视化界面,适合对集群系统的自动化监控。其精心设计的数据结构和算法使得监控端到被监控端的连接开销非常低。目前已经有成千上万的集群正在使用这个监控系统,可以轻松的处理2000个节点的集群环境。

    3、Cacti(英文含义为仙人掌)是一套基于PHP、MySQL、SNMP和RRDtool开发的网络流量监测图形分析工具,它通过snmpget来获取数据使用RRDtool绘图,但使用者无须了解RRDtool复杂的参数。提供了非常强大的数据和用户管理功能,可以指定每一个用户能查看树状结构、主机设备以及任何一张图,还可以与LDAP结合进行用户认证,同时也能自定义模板。在历史数据展示监控方面,其功能相当不错。 
    Cacti通过添加模板,使不同设备的监控添加具有可复用性,并且具备可自定义绘图的功能,具有强大的运算能力(数据的叠加功能)

    4、Nagios是一个企业级监控系统,可监控服务的运行状态和网络信息等,并能监视所指定的本地或远程主机状态以及服务,同时提供异常告警通知功能等。 
    Nagios可运行在Linux和UNIX平台上。同时提供Web界面,以方便系统管理人员查看网络状态、各种系统问题、以及系统相关日志等 
    Nagios的功能侧重于监控服务的可用性,能根据监控指标状态触发告警。 
    目前Nagios也占领了一定的市场份额,不过Nagios并没有与时俱进,已经不能满足于多变的监控需求,架构的扩展性和使用的便捷性有待增强,其高级功能集成在商业版Nagios XI中。

    5、Smokeping主要用于监视网络性能,包括常规的ping、www服务器性能、DNS查询性能、SSH性能等。底层也是用RRDtool做支持,特点是绘制图非常漂亮,网络丢包和延迟用颜色和阴影来标示,支持将多张图叠放在一起,其作者还开发了MRTG和RRDtll等工具。 
    Smokeping的站点为:http://tobi.oetiker.cn/hp

    6、开源监控系统OpenTSDB用Hbase存储所有时序(无须采样)的数据,来构建一个分布式、可伸缩的时间序列数据库。它支持秒级数据采集,支持永久存储,可以做容量规划,并很容易地接入到现有的告警系统里。 
    OpenTSDB可以从大规模的集群(包括集群中的网络设备、操作系统、应用程序)中获取相应的采集指标,并进行存储、索引和服务,从而使这些数据更容易让人理解,如Web化、图形化等。

    王牌监控

    1、Zabbix是一个分布式监控系统,支持多种采集方式和采集客户端,有专用的Agent代理,也支持SNMP、IPMI、JMX、Telnet、SSH等多种协议,它将采集到的数据存放到数据库,然后对其进行分析整理,达到条件触发告警。其灵活的扩展性和丰富的功能是其他监控系统所不能比的。相对来说,它的总体功能做的非常优秀。 
    从以上各种监控系统的对比来看,Zabbix都是具有优势的,其丰富的功能、可扩展的能力、二次开发的能力和简单易用的特点,读者只要稍加学习,即可构建自己的监控系统。

    2、小米的监控系统:open-falcon。open-falcon的目标是做最开放、最好用的互联网企业级监控产品。

    3、OWL是TalkingData公司推出的一款开源分布式监控系统OWLgithub地址

    三方监控:

    现在市场上有很多不错的第三方监控,比如:监控宝、监控易、听云、还有很多云厂商自带监控,但是在这里我们不打算着重介绍,如果想了解三方监控可自行上官网咨询。(避免说广告植入)

     

    4 监控流程

    上面介绍了这么多,那么到底选择什么监控工具最合适呢,我这里推荐几款开源监控工具:zabbix、Open-Falcon、LEPUS天兔(专用于监控数据库)。 
    但是本文还是基于zabbix来构建整个监控体系生态圈。 
    那么下面我们就来聊聊,zabbix的整个流程: 

    监控流程

     

    监控流程

    1.数据采集: Zabbix通过SNMP、Agent、ICMP、SSH、IPMI等对系统进行数据采集 
    2.数据存储: Zabbix存储在MySQL上,也可以存储在其他数据库服务 
    3.数据分析: 当我们事后需要复盘分析故障时,zabbix能给我们提供图形以及时间等相关信息,方便我们确定故障所在。 
    4.数据展示: web界面展示、(移动APP、java_php开发一个web界面也可以) 
    5.监控报警:电话报警、邮件报警、微信报警、短信报警、报警升级机制等(无论什么报警都可以) 
    6.报警处理:当接收到报警,我们需要根据故障的级别进行处理,比如:重要紧急、重要不紧急,等。根据故障的级别,配合相关的人员进行快速处理。

     

    5 监控指标

    我们上面了解了监控方法、目标、流程、也了解了监控有哪些工具,可能有人会疑惑,我们具体要监控写什么东西,那么我在这里进行了分类整理: 
    硬件监控 
    系统监控 
    应用监控 
    网络监控 
    流量分析 
    日志监控 
    安全监控 
    API监控 
    性能监控 
    业务监控 

     

    5.1 硬件监控

    早期我们通过机房巡检的方式,查看硬件设备灯光闪烁情况判断是否故障,这样非常浪费人力,并且是重复性无技术含量的工作,大家懂得。 

    硬件监控

     

    硬件监控

    当然我们现在可以通过IPMI对硬件详细情况进行监控,并对CPU、内存、磁盘、温度、风扇、电压等设置报警设置报警阈值(自行对监控报警内容编写合理的报警范围) 
    IPMI监控硬件服务参考资料 

    IPMI

     

    IPMI

    IPMI工具无法获取到硬件的状态,可以借助MegaCli工具探测Raid磁盘队列状态 
    zabbix提供IPMI监控模板:Zabbix IPMI Interface 
    系统自带的IPMI模板只能监控,风扇,电源,和部分温度

     

    5.2 系统监控

    中小型企业基本全是Linux服务器,那么我们肯定是要监控起系统资源的使用情况,系统监控是监控体系的基础。

    监控主要对象: 

    系统监控

     

    CPU有几个重要的概念:上下文切换、运行队列和使用率

    这也是我们CPU监控的几个重点指标。 
    通常情况,每个处理器的运行队列不要高于3,CPU 利用率中用“户态/内核态”比例维持在70/30,空闲状态维持在50%,上下文切换要根据系统繁忙程度来综合考量。

    针对CPU常用的工具有:htop、top、vmstat、mpstat、dstat、glances

    zabbix提供系统监控模板:Zabbix Agent Interface

     

    cpu_uilt

    CPU整体状态

     

    上下文

    上下文切换

     

    load

    负载状态

     

    内存:通常我们需要监控内存的使用率、SWAP使用率、同时可以通过zabbix描绘内存使用率的曲线图形发现某服务内存溢出等。

    针对内存常用的工具有: free、top、vmstat、glances

     

    memroy

    内存使用率

     

    IO分为磁盘IO和网络IO。除了在做性能调优我们要监控更详细的数据外,那么日常监控,只关注磁盘使用率、磁盘吞吐量、磁盘写入繁忙程度,网络也是监控网卡流量即可。

    常用工具有:iostat、iotop、df、iftop、sar、glances 

    使用率

    磁盘使用率

     

     

    吞吐

    磁盘读/写吞吐

     

     

    次数

    磁盘读/写次数

     

     

    network

    网卡进出口流量

     

     

    tcp状态

    TCP11种状态信息

     

    其它的系统监控还有运行的进程端口、进程数、登陆用户、Open File等(详细查看zabbix自带OS Linux模板) 

    其他

    其他相关监控

     

     

    5.3 应用监控

    把硬件监控和系统监控研究明白后,我们进一步操作是需要登陆到服务器上查看服务器运行了哪些服务,都需要监控起来。 
    应用服务监控也是监控体系中比较重要的内容,例如: 
    LVS、Haproxy、Docker、Nginx、PHP、Memcached、Redis、MySQL、Rabbitmq等等,相关的服务都需要使用zabbix监控起来。

     

    nginx

    nginx_status

     

    php-fpm

    PHP-FPM_status


    Redis

    Redis_status

     

    jvm

    JVM监控

     

    zabbix提供应用服务监控:Zabbix Agent UserParameter 
    zabbix提供的Java监控:Zabbix JMX Interface 
    percona提供MySQL数据库监控:percona-monitoring-plulgins

     

    5.4 网络监控

    作为一个针对全国用户的电商网站,时刻掌握各地到机房的网络状态也是必须的。 
    网络监控是我们构建监控平台是必须要考虑的,尤其是针对有多个机房的场景,各个机房之间的网络状态,机房和全国各地的网络状态都是我们需要重点关注的对象,那么如何掌握这些状态信息呢?我们需要借助于网络监控工具Smokeping。

    Smokeping 是rrdtool的作者Tobi Oetiker的作品,是用Perl写的,主要是监视网络性能,www 服务器性能,dns查询性能等,使用rrdtool绘图,而且支持分布式,直接从多个agent进行数据的汇总。

    同时,由于自己监控点比较少,还可以借助很多商业的监控工具,比如监控宝、听云、基调、博瑞等。同时这些服务提供商还可以帮助你监控CDN的状态。

     

    网络监控

    smokeping

     

    性能监控1

     

    性能监控2

    监控宝

     

     

    5.5 流量分析

    网站流量分析对于运维人员来说,更是一门必须掌握的知识了。比如对于一家电商公司来说: 
    通过对订单来源的统计和分析,可以了解我们在某个网站上的广告投入有没有收到预期的效果。 
    可以区分不同地区的访问人数、甚至商品交易额等。

    百度统计、google分析、站长工具等等,只需要在页面嵌入一个js即可。 
    但是,数据始终是在对方手中,个性化定制不方便,于是google出一个叫piwik的开源分析工具

     

    piwik

    piwik

     

    百度统计

    百度统计

     

     

    5.6 日志监控

    通常情况下,随着系统的运行,操作系统会产生系统日志,应用程序会产生应用程序的访问日志、错误日志,运行日志,网络日志,我们可以使用ELK来进行日志监控。

    对于日志监控来说,最见的需求就是收集、存储、查询、展示,开源社区正好有相对应的开源项目: 
    logstash(收集) + elasticsearch(存储+搜索) + kibana(展示) 
    我们将这三个组合起来的技术称之为ELK Stack,所以说ELK Stack指的是Elasticsearch、Logstash、Kibana技术栈的结合。

    如果收集了日志信息,那么如果部署更新有异常出现,可以立即在kibana上看到。 

    elk

    Elk日志展示

     

    当然也可以通过Zabbix过滤错误日志来进行告警。 

    zabbix_rizi

    zabbix日志展示

     

     

    5.7 安全监控

    虽然Linux开源的安全产品不少,比如四层iptables,七层WEB防护nginx+lua实现WAF,最后将相关的日志都收至Elkstack,通过图形化进行不同的攻击类型展示。但是始终是一件比较耗费时间,并且个人认为效果并不是很好。这个时候我们可以选择接入第三方服务厂商。 

    三方

     

    sf

     

    sff

    某某三方安全

     

    三方厂商提供全面的漏洞库,涵盖服务、后门、数据库、配置检测、CGI、SMTP等多种类型 
    全面检测主机、Web应用漏洞自主挖掘和行业共享相结合第一时间更新0day漏洞,杜绝最新安全隐患

     

    5.8 API监控

    由于API变得越来越重要,很显然我们也需要这样的数据来分辨我们提供的 API是否能够正常运作。 
    监控API接口GET、POST、PUT、DELETE、HEAD、OPTIONS的请求 
    可用性、正确性、响应时间为三大重性能指标

     

    API

    API监控

     


    api

    三方API监控

     

    响应时间
    响应时间2

    响应时间

     

     

    5.9 性能监控

    全面监控网页性能,DNS响应时间、HTTP建立连接时间、页面性能指数、响应时间、可用率、元素大小等 
    zabbix提供URL监控:Zabbix Web 监控 
    web监控

    Zabbix站点监控

     

    性能监控

     

    性能监控2

     

    性能监控33

     

     

    终端响应时间

    终端响应时间

     

    第三方监控监控大盘。各类图表一目了然,全面体现网页性能健康状况。

     

    5.10 业务监控

    没有业务指标监控的监控平台,不是一个完善的监控平台,通常在我们的监控系统中,必须将我们重要的业务指标进行监控,并设置阈值进行告警通知。比如电商行业:

    每分钟产生多少订单, 
    每分钟注册多少用户, 
    每天有多少活跃用户, 
    每天有多少推广活动, 
    推广活动引入多少用户, 
    推广活动引入多少流量, 
    推广活动引入多少利润, 
    等等 重要指标都可以加入zabbix上,然后通过screen展示。 
    注:由于业务监控图表,涉及到隐私的数据太多,就不截图。

     

    6 监控报警

    故障报警通知的方式有很多种,当然我们最常用的还是短信,邮件 

    监控报警

     

    手机短信

    短信报警

     

    邮件报警

    邮件报警

     

     

    7 报警处理

    一般报警后我们故障如何处理,首先,我们可以通过告警升级机制先自动处理,比如nginx服务down了,可以设置告警升级自动启动nginx。 
    但是如果一般业务出现了严重故障,我们通常根据故障的级别,故障的业务,来指派不同的运维人员进行处理。 
    当然不同业务形态、不同架构、不同服务可能采用的方式都不同,这个没有一个固定的模式套用。 

    报警处理

     

     

    8 面试监控

    在运维面试中,常常会被问题监控相关的问题,那么这个问题到底该如何来回答,我针对本文给大家提供了一个简单的回答思路。

    1.硬件监控。 
    通过SNMP来进行路由器交换机的监控(这些可以跟一些厂商沟通来了解如何做)、服务器的温度以及其他,可以通过IPMI来实现。当然如果没有硬件全都是云,直接跳过这一步骤。 
    2.系统监控。 
    如CPU的负载,上下文切换、内存使用率、磁盘读写、磁盘使用率、磁盘inode使用率。当然这些都是需要配置触发器,因为默认太低会频繁报警。 
    3.服务监控。 
    比如公司用的LNMP架构,nginx自带Status模块、PHP也有相关的Status、MySQL的话可以通过percona官方工具来进行监控。Redis这些通过自身的info获取信息进行过滤等。方法都类似。要么服务自带。要么通过脚本来实现想监控的内容,以及报警和图形功能。 
    4.网络监控。 
    如果是云主机又不是跨机房,那么可以选择不监控网络。当然你说我们是跨机房以及如何如何。推荐使用smokeping来做网络相关的监控。或者直接交给你们的网络工程师来做,因为术业有专攻。 
    5.安全监控。 
    如果是云主机可以考虑使用自带的安全防护。当然也可以使用iptables。如果是硬件,那么推荐使用硬件防火墙。使用云可以购买防DDOS,避免出现故障导致down机一天。如果是系统,那么权限、密码、备份、恢复等基础方案要做好。web同时也可以使用Nginx+Lua来实现一个web层面的防火墙。当然也可以使用集成好的openresty。 
    6.Web监控。 
    web监控的话题其实还是很多。比如可以使用自带的web监控来监控页面相关的延迟、js响应时间、下载时间、等等。这里我推荐使用专业的商业软件,监控宝或听云来实现。毕竟人家全国各地都有机房。(如果本身是多机房那就另说了)
    7.日志监控。 
    如果是web的话可以使用监控Nginx的50x、40x的错误日志,PHP的ERROR日志。其实这些需求无非是,收集、存储、查询、展示,我们其实可以使用开源的ELKstack来实现。Logstash(收集)、elasticsearch(存储+搜索)、kibana(展示) 
    8.业务监控。 
    我们上面做了那么多,其实最终还是保证业务的运行。这样我们做的监控才有意义。所以业务层面这块的监控需要和开发以及总监开会讨论,监控比较重要的业务指标,(需要开会确认)然后通过简单的脚本就可以实现,最后设置触发器即可 
    9.流量分析。 
    平时我们分析日志都是拿awk sed xxx一堆工具来实现。这样对我们统计ip、pv、uv不是很方便。那么可以使用百度统计、google统计、商业,让开发嵌入代码即可。为了避免隐私也可以使用piwik来做相关的流量分析。 
    10.可视化。 
    通过screen以及引入一些第三方的库来美化界面,同时我们也需要知道,订单量突然增加、突然减少。或者说突然来了一大波流量,这流量从哪儿来,是不是推广了,还是被攻击了。可以结合监控平来梳理各个系统之间的业务关系。 
    11.自动化监控。 
    如上我们做了那么多的工作,当然不能是一台一台的来加key实现。可以通过Zabbix的主动模式以及被动模式来实现。当然最好还是通过API来实现。

    12.分布式监控

     

    9 监控总结

    真正想做到更完整的监控体系,目前的开源软件,确实无法很好的满足,有条件的公司都开始自己开发自己的监控系统,比如小米开源的Open-Falcon。 
    也有比较好的开源的监控框架如Sensu等,再加上influxdb、grafana可以用来定制符合自己企业的监控平台。

    当然我说的还是很简单,经验有限、思路也仅能提供这么多。 

    文章参考

    https://www.cnblogs.com/anytiwe/articles/6723993.html

    展开全文
  • Linux知识体系总结(2021版)

    千次阅读 多人点赞 2021-05-31 21:17:39
    Linux有上百种不同的发行版,如基于社区开发的debian、archlinux,和基于商业开发的Red Hat Enterprise Linux、SUSE、Oracle Linux等。 Linux,全称GNU/Linux,是一套免费使用和自由传播的类Unix操作系统,是一个...
  • 人工智能知识体系

    千次阅读 2018-12-13 15:54:39
    本阶段主要从数据分析、概率论和线性代数及矩阵和凸优化这四大块讲解基础,旨在训练大家逻辑能力,分析能力。拥有良好的数学基础,有利于大家在后续课程的学习中更好的理解机器学习和深度学习的相关算法内容。同时...
  • 企业商业智能平台体系分析[1]

    千次阅读 2009-11-16 21:04:00
    近年来,商业智能(Business Intelligence,简称BI)的兴起成为已经成为企业决策信息化的热点,BI软件市场也在最近几年得到了迅速增长。在国外,几家大的软件巨头包括 IBM和Oracle已经打造了自己的BI实
  • 最全大数据技术知识体系

    千次阅读 2019-04-26 11:31:27
    大数据技术知识体系 大数据技术知识体系 --持续更新,建议收藏 最早提出“大数据”时代到来的是全球知名咨询公司麦肯锡,麦肯锡称:“数据,已经渗透到当今每一个行业和业务职能领域,成为重要的生产因素。人们...
  • 架构设计——架构知识体系

    万次阅读 多人点赞 2018-08-23 13:45:58
    架构设计——架构知识体系   1、什么是架构和架构本质 在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。 我们主要针对互联网服server系统...
  • CISP V4.1 知识体系大纲 知识点梳理

    千次阅读 2018-11-28 17:10:44
    知识知识点 掌握要求 一、知识域:信息安全保障     1.1 知识子域:信息安全保障基础      1.1.1 信息安全概念  了解理解国际标准化组织、美国、欧盟等对信息安全的定义; 3 ...
  • java知识体系介绍

    万次阅读 2018-01-03 09:52:45
    百大项目第三阶段:需求分析、概要和详细设计 158 Struts2 框架 159 Hibernate 框架 160 Spring 框架 162 阶段项目课程14 164 Spring MVC技术 166 MyBatis 框架 168 EasyUI技术 170 RBAC技术 170 shiro安全...
  • 敏捷开发知识体系笔记

    万次阅读 多人点赞 2015-11-03 16:30:22
    敏捷开发知识体系整体框架敏捷开发工程实践项目管理 迭代开发 风险价值生命周期 多级项目规划 完整团队 每日站立会议 任务板 燃尽图 需求管理 需求订单 业务流程草图 用例驱动开发 用户故事 架构 演进的架构 演进的...
  • 建立自己的知识体系,就像从一个四海为家的人到给自己建一栋安居的房子,你应该先问问自己为什么要这样做?构建自己的核心价值么?这句话在职业规划中老生常谈了,你有么? (1)我为什么要去学习? 作为...
  • TTPPRC —— 商业分析模型

    千次阅读 2019-09-30 13:55:51
    通过这个模型,可以让不具备专业商业知识的大众都能容易得出商业分析结果。  此文是读者阅读原文后,而整理的一份笔记。原文地址:https://zhuanlan.zhihu.com/p/20325151 ,作者:JOIN于宙( 非本人 )。 侵权即删...
  • 软件工程知识体系指南综述*

    千次阅读 2007-12-25 17:18:00
    软件工程知识体系指南综述*万江平,安诗芳,黄德毅 (华南理工大学工商管理学院,广东广州510640)【摘要】首先许述软件工程知识体系指南的历史及其五大目标,并进一步说明了其层次结构以及相关的八个学科;详细分析了...
  • 运维知识体系V2.0-赵班长

    千次阅读 2017-09-14 09:02:30
    运维知识体系-V2.0 赵班长 运维架构层级/运维角度 内容描述/主要技术关键词 监控体系 自动化/DevOps 云计算 客户端层 浏览器 Cookie、浏览器缓存协商(Last-Modified、Expires、Etag)、组件分离、...
  • 设计师需要的知识体系

    千次阅读 2012-09-25 09:48:22
    产品设计师面对复杂、庞大的制造业系统以及多元化的市场,其知识体系要同时具备广度和深度。设计是循序渐进、不断深入的过程,因此我们面对的是交错的学科体系,以及深入的技术探究。当国内工业设计教育界还在热烈地...
  • 如何快速全面建立自己的大数据知识体系? chenjj 2017-08-01 大数据, 大数据应用, 热门新闻 729 views 1 很多人都看过不同类型的书,也接触过很多有关大数据方面的文章,但都是很零散不成...
  • 数字图像处理知识体系小结

    万次阅读 多人点赞 2012-12-13 21:26:22
    花了点时间整理了一下数字图像处理知识体系,从宏观上把握图像处理,使自己的学习思路就更加清晰。 1.本文大部分内容来自:http://blog.csdn.net/byxdaz/article/details/4375228 2.有些内容待添加,特别是opencv...
  • 《NPDP 产品经理认证知识体系指南》读书笔记 前言 以下10条问题,请大家认真思考一下 为什么,从事多年的产品经理工作,依然没有做出类似Uber、微信的产品? 为什么,外人时常误解的认为产品经理的工作门槛很...
  • 数字图像处理知识体系小结(转)

    万次阅读 2015-10-05 15:43:47
    在浏览博客是看到一篇文章,对图像处理领域的算法和理论总结的很到位,便转载了...花了点时间整理了一下数字图像处理知识体系,从宏观上把握图像处理,使自己的学习思路就更加清晰。 1.本文大部分内容来自:http://
  • 运维知识体系V1.9-赵班长 运维知识体系-V1.9 By:赵舜东(赵班长) 【转载请注明来自于-运维社区:https://www.unixhot.com/】 运维架构层级/运维角度 内容描述/主要技术关键词 监控体系 自动化/DevOps ...
  • 数据仓库、商业智能的体系结构

    千次阅读 2011-06-30 17:49:00
    来源:http://ajava.org/readbook/db/dbgcsks/12413.html 16.2 数据仓库、商业智能的体系结构如图16-5所示是数据仓库/商业智能的完整的体系结构图,根据数据的不同形态,整个体系被划分为4个大的层面,并根据数据...
  • 项目管理知识体系指南(PMBOK 指南) 第6版——笔记

    万次阅读 多人点赞 2019-05-31 16:16:13
    项目管理十大知识领域,五大管理过程组,49个过程。如下表格: 项目:项目的定义 : (Project Management Institute) 项目是为创造独特的产品、服务或成果而进行的临时性工作。 三特点:独特、临时、渐进 项目...
  • 那人工智能知识体系有哪些内容呢? 下面是新一代人工智能知识体系大全图谱: 中国人工智能发展现状与未来 对于中国而言,人工智能的发展是一个历史性的战略机遇,对缓解未来人口老龄化压力、应对可持续...
  • 从事无线通信产品射频设计调测工作这么多年,时常会反思一下自己的知识技术体系以及心态是否能让自己胜任当前的工作。今天,特意梳理总结一下,一方面给新入射频行业的人一个参考,另一方面也看看自己在哪个方面还...
  • 渗透测试2---软件安全测试知识体系

    千次阅读 2019-10-22 16:22:49
    护网行动攻击方有两类,第一类是由安全厂家(包含深信服、启明星辰、安恒、绿盟、长亭等)派出安全专家组成的商业攻击队;第二类是由四大军区派出安全攻防专家组成的军队攻击队。 攻击方的目标是拿下DNS服务器、...
  • 运维必知必会的监控知识体系全梳理总结

    万次阅读 多人点赞 2017-09-06 09:56:16
    当然,对监控不是很明白的朋友们,看了以下文章可能会对监控整个体系有比较深刻的认识。 一、监控目标 每个人由于所在的行业、公司、业务、岗位不同,对监控的理解也不尽相同,但是我们需要注意,监控是

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 45,168
精华内容 18,067
关键字:

商业分析知识体系