精华内容
下载资源
问答
  • 2021-02-15 19:19:12

    作者:随亦
    本篇介绍:个人信息收集
    本篇为第1篇/共9篇
    下一篇:基于国内法律法规的企业数据合规体系建设经验总结(二)


    引子

    在离开前公司之后(2020.06),我来到新的公司担任安全部负责人,负责新公司的安全架构设计与安全体系建设,由于新公司的业务都是面向国内的,因此在建设隐私合规体系时,参照的都是国内的法律法规标准。本系列即以国内法律法规为基准,抛砖引玉,来探讨纯国内业务企业的隐私合规体系建设。

    前言

    数据保护应当遵循“四个全覆盖”的要求:覆盖数据的全生命周期覆盖业务经营、风险管理和内部控制流程中的全部数据覆盖内部数据和外部数据覆盖所有分支机构和附属机构

    具体来说,为确保数据相关运作合法合规,企业应将数据保护体系贯彻数据的全生命周期,配合建立网络安全相关法律法规要求的各项制度,符合法律法规对于个人信息保护的各项规定要求。参照相关国家标准的细化要求,进行个人信息全生命周期的合规安排。

    回到本篇主题,那何为个人信息收集?

    对于这个问题,《个人信息安全规范》第3.5条、《个人信息告知同意指南》第5.1条、《网络安全法》第41条均对个人信息收集做了说明,我们来看看《个人信息安全规范》第3.5条,其他的相关法规条款请读者自行查阅。

    《个人信息安全规范》第3.5条规定:个人信息收集是指获得个人信息的控制权的行为,包括直接收集个人信息和间接收集个人信息两种方式。其中直接收集个人信息是指个人信息主体主动提供、通过与个人信息主体交互或记录个人信息主体行为等自动采集的行为;间接个人信息收集是指通过共享、转让、搜集公开信息等间接获取个人信息的行为。

    接下来,我将从个人信息收集的合法性必要性被收集者同意征得被收集者同意的例外隐私政策优化间接获取个人信息的要求等六方面来探讨个人信息收集的合规化。

    一、合法性

    《个人信息安全规范》第5.1条规定了收集个人信息的合法性要求,我们在实践中可参照它的要求来进行实施:

    1、不应以欺诈、诱骗、误导的方式收集个人信息

    不能以欺诈、诱骗等不正当方式误导用户同意收集个人信息或打开可收集个人信息的权限,比如故意欺瞒、掩饰收集个人信息的真实目的。

    在实际实施中,可以通过实际的技术测试来判断是否有误导行为。但对于宣称收集信息只用于A功能而实际上却用于B功能的行为,除了通过抓包测试外,也可以与开发面谈问询,例如B功能的实现肯定需要个人信息做为支撑,但它没有明面上收集,那这里的个人信息从何而来?

    2、不应隐瞒产品或服务所具有的收集个人信息的功能

    首先,《隐私政策》中不能存在“等、例如”字样,这是规定的。也就是说,我们需要全面的梳理业务功能,而不能因为懒惰,在隐私政策中使用“等、例如”字样,进而可避免宣称收集信息只用于A功能而实际上却用于B功能的行为。

    在实际监管中,抓包测试就能发现一切端倪。监管机构也是用这种方式做测试,然后对不合规APP进行通报整改的,除了监管机构,合规比较严格的客户也会进行尽调审计。

    3、不应从非法渠道获取个人信息

    这个行为是指,通过黑市等非法渠道获取来源不明的个人信息。一般的正规公司都不存在这一行为。

    需要注意的是,这里除了自身不应从黑市等非法渠道获取个人信息外。对于共享或授权个人信息数据给我们的合作方,也应对其数据来源、是否获得用户授权以及授权的范围进行必要的尽调,以防止产生连带法律责任。

    二、必要性

    根据《APP违法违规认定方法》第4条和《APP自评估指南》评估项7,我们可以实践满足个人信息收集的必要性要求,必要性的要求包括:

    1、收集的个人信息类型或打开的可收集个人信息的权限应为现有业务功能所必需或有合理的应用场景

    收集的个人信息类型或打开的可收集个人信息权限不得与现有业务功能的应用场景无关,不得过度收集或过度索权。

    实践中典型的问题一般包括:

    1)过度收集用户通讯录、短信、通话记录等,或收集身份证号、人脸、指纹等作为应用开启使用的前提条件。
    2)通过积分、奖励等方式诱导用户,收集身份证号、人脸、指纹等信息。
    3)APP在用户还未使用相关功能或服务时,提前申请开启通讯录、定位、短信、相机等权限。

    需要注意的是,“现有业务功能”是指现有的,而非过去或准备开发的新业务功能。

    2、不得因用户不同意收集非必要个人信息或打开非必要权限,而拒绝提供业务功能

    实践中存在很多通过拒绝提供业务功能,变相强迫用户同意收集非必要个人信息或打开非必要权限的行为。最典型的问题就是APP在运行时向用户索取与当前服务场景无关的权限,用户拒绝后,应用直接退出或关闭。

    产生这种现象的原因,一般是开发人员因为懒惰,采取了一刀切的方式解决合规要求,此时需要安全向产品、开发普及其中的合规要求,从而使产品走向合规。

    3、当新增业务功能申请收集的个人信息超出用户原有同意范围,若用户不同意,不得拒绝提供原有业务功能,但新增业务功能取代原有业务功能的除外

    在实践中,一个应用更新新的功能非常普遍,此时就要避免出现新功能的索权上继续使用一刀切的模式,使用户不同意新功能的索权导致整个应用都不能使用。而解决这个问题的方法和上个一样,需要安全向产品、开发普及其中的合规要求,从而使产品走向合规。

    4、收集个人信息的频繁程度不得超出业务功能的实际需要

    在实践中典型的问题是按照一定的频次收集位置信息、IMEI或频繁读取通讯录、短信、图片等。一般情况下,公司存在该方面业务需要的,都没有太大问题,因为如何才算得上频繁并没有考量标准。但需要我们重点关注的,就是业务功能根本不需要这些数据,却进行频繁收集的情况。

    5、不得仅以改善服务质量、提升用户体验、定向推送信息、研发新产品等为由,强制要求用户同意收集个人信息

    前面我们说了,收集的个人信息必须是要有对应的业务功能的,因此,在实践中,APP可以将改善服务质量、提升用户体验、定向推送信息、研发新产品等目的与其他业务功能相结合,从而确保使用个人信息的类型与具体业务功能相对应。

    6、不得要求用户一次性同意打开多个可收集个人信息的权限,用户不同意则无法使用

    对于一揽子收集的问题有一个特殊情况,Android 6.0以前,APP在安装前需要先获取所有权限,得到用户同意后才能进行安装,Android 6.0及之后谷歌才开发了即时权限获取功能,即用到这个权限的时候再申请,不再安装前一揽子获取。而目前市面上APP基本都还支持Android 6.0之前的版本,这属于不可抗力因素。

    但是对于Android 6.0及之后的系统,仍一揽子收集就是我们自己的责任了,在实践中我们通过简单的测试就能判断它是否合规。同时,在实际测试中,我们应当注意,用户不同意应仅影响与所拒绝提供个人信息相关的业务功能,不能影响其他业务功能的正常使用,不得以不同意一揽子授权为理由不提供任何单一服务。

    7、不得在用户明确拒绝后继续频繁索要权限、打扰用户

    实践中存在很多用户明确拒绝权限申请后,仍向用户频繁弹窗申请开启与当前服务场景无关的通讯录、定位、短信、相机等权限的问题,严重影响用户体验。工信部和各省监管机构也屡次通报了存在这种问题的APP。

    这种问题只需简单的测试就能发现,因此在APP上线前,可以先做好合规测试。

    三、被收集者同意

    对于被收集者同意,根据《网络安全法》第41条的分析,具体的要求包括:

    1、不得在征得用户同意前就开始收集个人信息或打开可收集个人信息的权限

    实践中常见的问题包括APP运行时,缺乏向用户明示且征求用户同意的环节,收集IMEI、设备MAC地址、通讯录等个人信息。或APP运行时,虽然有向用户并经用户同意的环节,但个人信息收集发生在用户同意前。

    在实际监管中,可以通过抓包测试,检测在征得用户同意前是否向服务端发送了个人信息,对于不合规的地方,可以要求开发进行修复改进。

    2、用户明确表示不同意后,不得收集个人信息或打开可收集个人信息的权限

    实践中有很多用户明确表示不同意后,仍收集个人信息或打开可收集个人信息权限的情况,网络运营者应当尊重用户意愿,在用户明确拒绝收集个人信息或打开可收集个人信息权限的请求后,不得收集个人信息或打开可收集个人信息的权限。

    此外,需要注意的是,用户明确拒绝收集个人信息或打开可收集个人信息权限的请求后,应仅影响与拒绝提供个人信息或打开可收集个人信息权限相关的业务功能,不得影响用户正常使用其他业务功能。

    3、实际收集的个人信息或打开的可收集个人信息的权限,应与声明并经用户同意的收集规则保持一致

    隐私政策的作用不仅在于告知用户并获得用户的同意,还在于网络运营者自身收集个人信息的约束。用户在悉知并同意隐私政策后,对网络运营者在个人信息收集处理上会形成合理期待。

    实践中可以先通过了解实际业务,优化隐私政策让隐私政策合规化,再通过技术测试来判断应用是否合规,对于与隐私政策不相符的地方,可连同产品、开发等人员进行合规化改进。

    4、不得以默认选择同意个人信息保护政策等非明示方式征求用户同意

    目前市面上常见的不合规现象包括:默认勾选同意、注册即表示同意等。而被监管机构通报的也大多属于这一类。

    在实践中,合规的方式应当是用户自主做出肯定性动作,肯定性动作包括主动勾选、主动点击、主动填写或输入、主动开启、主动签名等方式。对于是否合规,通过简单的测试即可得出结论。

    5、不得未经用户同意更改其设置的可收集个人信息权限状态,如APP更新时自动将用户设置的权限恢复到默认状态

    对于利用APP更新等方式在未经用户同意的情况下,隐秘修改用户设置的可收集个人信息权限状态的行为,如果没有专门去查看权限状态,很难发现该变动。实际测试中可通过更新APP来手动验证权限是否有变动。

    APP申请调用可收集个人信息权限均应获得用户同意,不得未经用户同意私自更改用户权限设置,不得利用系统更新升级去更改原有的系统权限设置。

    6、收集个人生物识别信息的特殊要求

    《个人信息安全规范》第5.4条规定:收集个人生物识别信息前,应单独向个人信息主体告知收集、使用个人生物识别信息的目的、方式和范围,以及存储实践等规则,并征得个人信息主体的明示同意。

    实践中,应当重点关注三个要点:

    1)告知方式:单独告知;
    2)告知内容:收集、使用个人生物识别信息的目的、方式和范围,以及存储实践等规则;
    3)同意方式:明示同意。

    四、征得被收集者同意的例外

    对于征集被收集者同意的例外情形,我们来看看《个人信息安全规范》第5.6条中是如何规定的:

    a)与个人信息控制者履行法律法规规定的义务相关的;

    举例:比如国家规定必需要纳税,纳税时收集个人信息的情况,无需征得你同意

    b)与国家安全、国防安全直接相关的;

    举例:我达不到这个高度,举不出例子

    c)与公共安全、公共卫生、重大公共利益直接相关的;

    举例:比如新冠肺炎期间要排查人员流动时收集个人信息的情况,无需征得你同意

    d)与刑事侦查、起诉、审判和判决执行等直接相关的;

    举例:比如当你犯法了公安机关调查你时收集个人信息的情况,无需征得你同意

    e)出于维护个人信息主体或其他个人的生命、财产等重大合法权益但又难以得到本人授权同意的;

    举例:比如你在昏迷时医生给你上药,需要收集你的生物个人信息的情况,无需征得你同意

    f)所涉及的个人信息是个人信息主体自行向社会公众公开的;

    举例:你自己发布出去的个人信息

    g)根据个人信息主体要求签订和履行合同所必须的;

    举例:比如要你履行xx合同的义务时,收集个人信息的情况,无需征得你同意

    h)从合法公开披露的信息中收集个人信息的;

    举例:比如从合法的新闻报道、政府公开等渠道收集个人信息的

    i)维护所提供产品或服务的安全稳定运行所必需的;

    举例:比如发现、处置产品或服务的故障

    j)个人信息控制者为新闻单位,且其开展合法的新闻报道所必需的;

    举例:关于新闻单位的,不举例

    k)个人信息控制者为学术研究机构,出于公共利益开展统计或学术研究所必要,且其对外提供学术研究或描述的结果时,对结果中所包含的个人信息进行去标识化处理的。

    举例:关于科研院所的,不举例

    五、隐私政策优化

    先科普个小知识,隐私政策的出现主要来源于当初欧盟的GDPR,在当时国内还没有相关法律,因此为了统一业务合规,大多数跨国公司在国内业务中也使用了隐私政策,而现在,《个人信息安全规范》中将其规定为个人信息保护政策。但由于隐私政策这个名称使用已久,我们今天仍称将其之为隐私政策

    企业设计隐私政策要符合自身的基本情况和所处行业的特征,不能生搬硬套。

    首先,要明确告知用户,企业收集、利用及保护个人信息的方式;其次,要使用浅显易懂的表达方式,明确告知用户收集数据的类型、使用目的,并在获得用户明确同意的情况下进行相关的数据操作;再次,要为用户删除数据、注销账户提供渠道,明确对用户数据的共享、发布方式,确保不会侵犯个人隐私;最后,要明确告知用户发生争议时的询问和投诉渠道,以及争议解决机制等。

    除此外,企业也要积极探索创新的隐私条款展现方式,例如,隐私条款使用弹窗告知、敏感信息采集进行即时提示等。

    隐私政策的作用在于两方面:

    1)向个人信息主体说明网络运营者收集处理个人信息的相关规则,保证个人信息知情权的有效实现,同时构成对网络运营者自身行为的约束;

    2)网络运营者获取个人信息主体授权的重要依据,在个人信息主体同意后,其可以作为网络运营者配合监督管理的重要机制,用以证明获得授权以减轻或豁免责任的重要凭证。

    依据国内法规,隐私政策的具体要求如下:

    1、隐私政策应符合独立性、易读性要求

    实践中,隐私政策应当以单独成文的形式发布,而不是作为用户协议、用户说明等文件中的一部分存在。

    同时,隐私政策应易于访问,在进入APP主界面后,应通过4次以内的点击就能够访问到隐私政策,并且隐私政策的链接位置应当突出、无遮挡,不应该出现隐私政策链接无效、文本无法显示的的情形。

    另外,隐私政策应易于阅读,不应该是清一色无差别文本,不应有文字过小过密、颜色过淡、模糊不清、冗长繁琐等问题,造成阅读起来一团浆糊。

    2、隐私政策应清晰说明各项业务功能及所收集个人信息的类型

    1)明示收集个人信息的业务功能和各项业务功能所收集的个人信息类型

    隐私政策中应当将收集个人信息的业务功能、各项业务功能所收集的个人信息类型逐项例举,不能因为懒惰梳理或为额外收集留有余地而使用“等、例如”字样。这个就不再多说了。

    2)显著标识个人敏感信息类型

    隐私政策中应对个人敏感信息类型进行额外的显著标识(如字体加粗、下划线、颜色等),需要注意的是,不能将所有收集的个人信息全部进行显著标识,如果全部进行显著标识,反而导致收集的个人敏感信息没有得到额外的显著标识。

    3、隐私政策应清晰说明个人信息处理规则及用户权益保障

    1)应说明公司运营主体的基本情况

    运营主体的基本情况应至少包含主体身份、联系方式。联系方式可以是隐私邮箱或客服电话等。

    2)应说明个人信息存储和超期处理方式

    隐私政策中应说明个人信息的如下情况:1)存放地域,如果在境外,应说明境外的哪个国家或地区;2)存储期限,应说明明确的存储期限,或法律规定范围内的最短期限;3)超期处理方式,如删除或匿名化等。

    3)应说明个人信息的使用规则

    隐私政策应明确说明收集使用个人信息的目的、方式、范围等,如果将个人信息用于用户画像、个性化展示等,应说明其应用场景和可能对用户产生的影响。

    4)应说明个人信息的出境情况

    如果存在个人信息出境的情况,应将出境的个人信息类型逐项列出并显著标识,显著标识的方式如字体加粗、下划线、颜色等。

    5)应说明个人信息安全保护措施和能力

    隐私政策中应对网络运营者在个人信息保护方面采取措施和具备能力进行说明,如身份鉴别、数据加密、访问控制、安全审计等。

    6)应说明对外共享、转让、公开披露个人信息规则

    如果存在个人信息对外共享、转让、公开披露的情况,隐私政策应明确以下内容:1)对外共享、转让、公开披露个人信息的目的;2)涉及的个人信息类型;3)接收方累心或身份;4)各自的安全和法律责任。

    应当注意的是,对于第三方的说明,应避免直接使用“提供给第三方”等类似过于宽泛的表述。

    7)应说明用户权利保障机制

    隐私政策中应对以下用户操作方法提供明确说明:1)个人信息查询;2)个人信息更正;3)个人信息删除;4)用户账户注销;5)撤回已同意的授权。

    需要注意的是,这些方法应该是方便用户操作且能切实保障用户该等权利的有效实现,避免出现一纸空文的情况。

    8)应说明用户申诉渠道和反馈机制

    隐私政策中至少提供以下一种投诉渠道:1)电子邮件;2)电话;3)传真;4)在线客服;5)在线表格。一般情况下,传真和表格是不会用到的。

    9)应具备时效性

    应明确标识隐私政策发布、生效或更新日期。按照一般实践,该标识一般在隐私政策的文首或文末。

    10)隐私政策更新

    一般在发生业务功能变更、个人信息出境变更、使用目的变更、联系方式变更等变更时,要进行隐私政策更新。在隐私政策更新后,可以通过弹窗方式提醒用户重新阅读,并通过用户手动点击确认、手动勾选等方式获得用户的再次授权。

    4、不应在隐私政策中设置免责等不合理条款

    隐私政策中不应存在免除自身责任、加重用户责任、排除用户主要权利条款,例如:隐私政策中列明 “您须对您本人在使用本APP所提供的服务时的一切行为、行动(无论是否故意)负全部责任”。

    这里的免除自身责任,是指运营者免除依照法律规定应当负有的强制性法律义务;这里的加重用户责任,是指运营者要求用户在法律规定的义务范围之外承担责任或损失;排除用户主要权利,是指运营者排除用户依照法律规定或依照合同的性质应当享有的主要权利。

    六、间接获取个人信息的要求

    在间接获取个人信息时,应当做到有限尽调!因为你不知道合作方共享或授权过来的数据是从哪来的。

    在实践中,有限尽调包括

    1)要求个人信息提供方书面说明个人信息来源和以获得的个人信息处理的授权同意范围,并提供其隐私政策等个人信息授权文本;

    2)要求个人信息提供方签署承诺函或在合作协议中设置专门条款,要求其承诺合法合规且获得用户同意获取并有权对外提供个人信息;

    3)对个人信息提供方进行必要的网络检索,检索内容包括个人信息方面的涉诉情况、行政处罚情况、通报情况、新闻报道情况、用户投诉情况等;

    4)持续关注个人信息提供方的数据合规情况,如定期抽查其个人信息授权文本等用户授权情况。

    如果发现个人信息提供方存在不合规情况,应视违法违规程度要求其限期改正或终止相关合作!


    本篇介绍:个人信息收集
    本篇为第1篇/共9篇
    下一篇:基于国内法律法规的企业数据合规体系建设经验总结(二)


    更多相关内容
  • 企业技术创新体系建设知识.pdf
  • 企业技术创新体系建设经验.doc
  • 企业技术创新体系建设经验.pdf
  • 企业技术创新体系建设初探汇编.pdf
  • 国有企业技术创新体系建设.docx
  • 国有企业技术创新体系建设.doc
  • 以区域技术创新体系为理论基础,研究地方政府在区域技术创新体系建设中所存在的问题,并对加强地方政府在构建区域技术创新体系的作用提出相应对策。提出在市场经济条件下,地方政府要根据新时期的职能重新定位,明确企业...
  • 积极组建企业院士工作站推进技术创新体系建设定义.pdf
  • 企业技术创新、研发管理和研发体系建设》课程大纲.doc
  • 科技与经济紧密结合建设企业为主体的技术创新体系 (2006年)
  • 搭建技术管理体系平台,建立完善技术管理的机制与制度,出台十几项管理制度与标准,覆盖科技规划、科技投标、项目管理、成果管理、知识产权、RAMS体系、标准化管理、技术市场等业务的制度建设,使现行技术创新体系成功...
  • 在梳理产业集群管理服务体系相关研究基础上,界定了产业集群管理创新服务体系的功能,确立了建设基于网络的产业集群协同平台、开展产业集群诊断与决策咨询服务以及开展技术转移协同管理服务等功能;提出了产业集群管理...
  • 企业信息化建设中的营销体系变革和创新市.docx
  • 随着国际市场的变化,国家能源供给...基于此,文章提出了技术创新与产业化评价指标体系,运用数据包络分析(DEA)评价法分析了技术创新与产业化效率。从而有利于加快高效矿井建设,做强做大煤炭产业,建设亿吨级煤炭大企业
  • 协同创新是低技术中小企业依靠技术优势获取竞争力的理性选择。...要促进低技术中小企业的创新与发展,提升其竞争力,必须构建协同创新体系、采取鼓励政策、完善知识产权保护制度,加强诚信文化建设和强化内部管理。
  • 通过对科技创新体系建设、重大科研项目攻关、科研项目管理、科技成果管理、知识产权保护及科技人才培养5个方面研究科技创新制度建设、科研项目管理方式、知识产权申请保护措施、人才激励等管理措施,以及对科技创新...
  • 本文分析了中小企业技术创新的优势,以及我国中小企业技术创新所面临的人才、技术、资金等方面的困境。并提出了法规建设、财税政策、扩展融资渠道、设立科技计划和完善社会服务体系诸方面的对策。
  • 煤炭行业作为中国最主要的能源行业之一,...文中运用DEA评价方法对企业技术创新活动进行评价,发现企业技术创新体系中存在的"瓶颈",对于增强煤炭企业竞争力、加快企业创新体系的建设具有重要的理论意义和实际应用价值。
  • 从煤炭企业安全科研体系建设存在的主要问题入手,分析了煤矿安全技术工作的薄弱环节,提出了安全科研体系建设的对策,制订了安全科研体系建设主要措施,构建了以总工程师为首的科技创新管理体制,从而逐步形成坚实的科技...
  • 针对煤炭技术创新的特点,分析企业进行产学研合作创新的动因,结合现状剖析存在的问题,从营造创新环境、加强企业合作创新主导地位、建设学习和创新型组织、健全企业合作创新制度、完善产学研合作服务体系等五方面提出...
  • 随着云计算、物联网、移动互联网等新一代信息技术的快速发展,人类产生的数据量呈指数级增长。据资料显示,2012年,全球数据量达到2.8ZB,预计到2020年,全球数据量将达到40ZB。大数据蕴含着巨大的价值,如今众多...

         随着云计算、物联网、移动互联网等新一代信息技术的快速发展,人类产生的数据量呈指数级增长。据资料显示,2012年,全球数据量达到2.8ZB,预计到2020年,全球数据量将达到40ZB。大数据蕴含着巨大的价值,如今众多企业已将数据视作企业的宝贵资产。然而,数据价值密度与数据总量成反比。面对巨大的数据规模,如何管理和利用数据,使其发挥价值是企业必须考虑的重要问题。大数据的价值所在使其面临着隐私和安全方面的威胁。大数据治理将组织的部门、流程、人等元素与数据的整个生命周期联系在了一起,对企业数据管理和数据资产价值有着至关重要的作用。

    《DGI数据治理框架》一文将数据治理定义为“数据相关事务的决策和授权的执行”,并进一步解释为信息处理过程决策权和职责的策略,约定了由谁负责处理哪些信息,并在什么情况下采用哪种方法,以及何时来执行。首先,大数据治理是信息治理计划的一部分,这是其定位。这就要求组织在制订信息治理框架时,必须将大数据纳入其中,比如在信息治理委员会中增加数据科学家,在信息治理目标中增加大数据治理目标等。其次,大数据治理主要是数据处理的一系列相关政策的制订,这是其内涵。再次,必须优化大数据,这是大数据治理的重点。最后,大数据必须变现,这是大数据治理的目的所在。

    大数据体量大、种类繁多,且价值密度低,组织必须对其进行优化,比如定义元数据、净化大数据、实施数据生命周期管理等。看似没有任何价值的单一数据集合在一起时,会发现新的价值,这是大数据价值体现的重要途径之一。而大数据价值的体现往往会涉及数据的隐私,这就要求组织在进行大数据价值体现时,必须注重大数据的隐私处理。组织将数据视作其资产的一种,要将其转化成组织可以使用的现金,而变现的方式可以是单纯地出售数据本身,也可以是利用数据开发新业务。

    一、企业实施大数据治理的必要性

    1、企业实现数据资源在组织内部的共享和交换的需要

    目前,大部分工业企业已经完成了ERP、CRM、供应链、协同办公等企业信息化系统的建设,但是由于数据分散在众多系统中,缺乏统一的数据定义和数据分类,因此在数据使用上存在数据不标准、数据不一致、数据完整性差等问题。

    数据不标准主要表现在不同系统之间描述同一业务实体的数据定义标准不同;数据不一致主要表现在相关联业务系统的数据不同步、各应用系统间存在数据编码规则不一致的问题,还有重复编码的问题;数据完整性差表现为缺少数据实体的关键信息。企业必须对各个系统的数据源以及输出的数据资产进行统一的数据治理,实现数据在不同组织和系统内的交换与共享。只有解决了数据问题,才能实现IT价值。

    2、提升海量数据资源质量的需要

    大数据时代数据产生的价值越来越大,各企业都在探索基于大数据的相关技术和应用模式,最终目的就是挖掘数据的价值,推动企业的发展。因为数据有可能是成本,也有可能是资产,能给企业带来重要的价值,是企业宝贵的资源。如果没有数据治理,数据的质量就无法保证,数据难以成为企业的资产,既使再多的业务和技术投入也都是徒劳。数据质量低下会导致企业在IT方面的重复投入,各种应用系统的价值难以有效地发挥出来,数据的问题甚至会使得企业错失商机,损失无法估量。

    数据治理是保证数据质量的必需手段,数据治理的价值贡献在于确保数据的准确性、可获取性、安全性、适度分享和合规使用。例如,可以对数据服务涉及的计算资源、数据资源制定标准化的统一管理规范,制定涵盖主数据、数据主题、数据质量、数据安全、数据共享等数据标准体系及数据管理体系。

    3、数据驱动企业进行科学决策的需要

    当今世界进入了数据爆炸的时代,数据成为企业重要的资产。企业涉及的数据类型,包括文本、图像、音频、视频等,分为静态数据和动态数据,实时数据和非实时数据,结构化数据、半结构化数据和非结构化数据,这些数据有些来源于企业的内部信息系统及设备,有些来源于外部的供应链和社交网络。数据驱动企业的决策成为时代发展的必然。

    数据治理能使企业清楚地认识自己的优势和劣势,有利于企业提高决策的合理性,为用户提供更加优质的服务。大数据时代,企业可以通过对数据的整合和分析,从中获取对企业有用的数据。新的数据技术手段,使得信息在企业内部不同部门之间有效、快速地传递,使得不同部门之间的交流、沟通更加透明,使得企业不同的利益主体能广泛地参与决策,从而提高决策的科学性和合理性。

    4、企业整合数据资源提升竞争力的需要

    在企业的生产经营活动中会产生大量的数据,企业需要对事务性数据、机器生成数据、社交媒体数据等内外部数据进行整合,特别是对与企业重大商业利益相关的数据资源的整合、分析与利用,从而指导企业的经营与发展。

    数据技术带来的不仅是技术的更新,还有管理方式的改变,数据治理不仅局限在企业的决策层,还包含管理层和业务层,数据治理能改善企业管理层与其他利益相关者的关系,使企业变得更加敏捷和高效,更注重用户体验的提升和需求的满足。例如,为解决日常的数据收集、数据处理效率较低、数据不一致的问题,可以通过元数据管理系统,建立采集元数据和元数据关系,提升跨系统的数据交互能力以及数据整合能力,进一步提升企业的核心竞争力。

    二、企业大数据治理现状

    伴随着大数据时代的到来,企业由于早期在信息系统构建中缺乏统一的全局规划,使得其在当前数据治理体系的构建中存在着一系列的问题,如果不能有效对这些问题进行解决,以构造出完善的数据治理体系,势必会对未来企业的发展带来不利的影响。

    1、大数据时代的定义及特征

    (1)大数据时代的定义

    我国已经进入了数字经济时代,必然会产生大量数据,大数据主要是指人们在日常工作、生产、生活中通过数字化的方式进行呈现和存储。也可以很通俗地将大数据理解成为巨大的数据信息,而伴随着人们的各种需求的不断增加,这种数据量还在不断的增加。举例来说,人们通过计算机互联网对视频和新闻的观看,都不同程度地促进了大数据时代的快速形成。

    (2)大数据时代的特征

    大数据时代具有如下几个明显的特征:

    数据量大。这是大数据时代最为突出的特征,这也是大数据时代本来就是基于大量数据信息所产生的是分不开的。

    速度很快。正是由于大量数据的产生,需要不断提升信息数据处理速度,才能跟上大数据时代的要求,而如果数据处理速度难以跟上,就不能满足信息的快速传播和扩散。

    种类很多。伴随着大数据时代的到来,计算机互联网技术在人们的生活中获得了非常广泛的应用,也使得数据来源变的更加丰富,相应地,数据的种类也变的更多。

    2、大数据时代企业数据治理现状

    在大数据时代下,企业在数据治理体系的构建过程中,主要面临着如下几个突出的问题:

    (1)数据定义的缺失

    所谓数据定义的缺失,就是企业的部分业务源系统以及外部数据源缺少关键业务元素定义。这是因为企业系统开发建设的出发点大多以满足客户业务交易为主要目标,对于统计分析涉及的数据要素项的定义不够关注,因此造成部分业务源系统和外部数据源的数据定义不完备。在这种情况下,就很容易造成企业的不同部门有着不同的理解,甚至在对同一个字段的理解也会产生很大的歧义。

    (2)数据标准的差异

    我国企业的早期信息化建设过程中,其业务源系统相对是比较分散的,很少有从全局的角度进行考虑,也就使得信息孤岛的现象比较突出,也带来了有关系统的物料、客户、供应商、会计科目、指标数据的不一致。正是由于企业在数据标准之间的差异,也使得各个信息系统之间的数据很难有效进行共享,也带来了企业的信息资源利用效率难以跟上实际需求,伴随着大数据时代的到来,更加使得挑战进一步扩大。

    (3)数据更新的滞后

    在大数据时代下,虽然企业为了满足各个系统与外部数据的内部访问,都提升了访问效率,减少手工数据传输,相同的信息经常会在不同系统之间进行冗余存放,不过由于对数据的更新滞后,很容易带来冗余数据的不一致,继而产生了数据质量的问题,这也是在企业在数据治理中应该重点关注的问题。

    (4)数据管控程度不高

    企业大数据建设的最终目标是促进企业对于数据应用,最大程度发挥数据价值。因此,在当前企业大数据的治理中,人们普遍重视数据应用,围绕应用中出现的数据关联、质量管理、业务协同等进行数据治理,而忽视数据治理体系中的管理机制、控制能力以及安全与隐私保护等。

    (5)数据治理机制不健全

    在大数据环境下,数据治理的主体趋于多元化,即一个数据治理流程往往需要多方参与。例如,在数据质量管理中,问题数据的发现、反馈、修正是一个多方参与的闭环流程,参与方包括:企业数据中心(数据治理方)、数据源头单位(数据提供方)、数据用户(数据使用方)等。这种多方协同治理的业务模式,对企业大数据治理制度和流程机制提出了更高要求。

    (6)技术支撑能力不足

    企业大数据治理体系的技术支撑需要涵盖大数据管理、存储、质量、共享与开放、安全与隐私保护等多个方面,当前相应的技术研究关联性和系统性还存在欠缺,都是侧重于点,而在整体上将技术关联起来还有问题。具体来说,以金融或电信运营商行业为典型代表的传统数据治理技术,是以基于主数据、元数据、数据规范的数据仓库管理系统,可实现特定领域和类型的应用级数据质量管理。但无法满足企业大数据环境下的海量、异构、多源、全格式(结构化、半结构化和非结构化)数据的治理需求。

    三、企业大数据治理成熟度评估

    1、大数据治理模型

    基于以上概念分析,只有更好的评估企业大数据治理成熟度,才能更好的指导企业大数据治理的建设。根据实践可以将大数据治理模型理解为人与组织、策略和能力的三维架构。人与组织是数据治理的主体,涉及企业中的各个职能部门及分子等,他们分别承担着不同的治理职责。策略是大数据治理的工具,能力是大数据治理的手段。下图所示为大数据治理模型三维架构。

    具体来说,人与组织包含利益相关者、治理委员会、管理委员会和内部员工。利益相关者指组织内部和外部环境中受组织决策和行动影响的任何相关者,数据的产生者、管理者、使用者和监督者等;治理委员会是组织治理数据的最高机构,负责作出数据相关事务的决定,并将数据治理标准和措施汇报给数据的利益相关者;管理委员会负责具体实施治理委员会制定的各项数据治理决定,并将数据治理结果汇报给治理委员会;内部员工是数据治理架构中不可或缺的一部分,贯彻执行数据治理委员会和管理委员会制定的各项数据治理策略。

    策略是组织制定的所有与大数据有关的数据优化、隐私保护和数据变现的准则和规范,包括组织数据治理的使命和愿景、治理指标、数据治理规则和定义、权利与职责、控制措施。数据治理的使命和愿景包括数据治理的整体目标,给予数据利益相关者持续与跨界的数据保护和服务,不合规准则引发的问题的解决方案等;数据治理指标定义了数据治理目标的衡量方法;数据治理规则和定义包括与数据相关的政策、标准、合规要求、业务规则和数据定义等;权利和职责规定了由谁来负责制订数据相关的决策、何时实施、如何实施,以及组织和个人在数据治理策略中该做什么;控制措施主要针对数据未治理风险防范和数据治理过程中可能发生的各类风险,以及如何做好数据隐私保护。

    能力则反映了组织进行数据治理所具备的条件和水平,包括元数据管理、数据质量管理、业务流程整合、主数据管理和信息生命周期管理。元数据是描述数据的数据,即描述数据和信息资源的信息。元数据管理就是整合大数据与企业的元数据库。数据质量管理准则包括数据识别、采集、测量、提升和论证质量、整合组织数据的方法,比如具备应对非结构化数据占据数据总量绝大部分情况的能力。业务流程整合要求组织制定的大数据治理计划必须与组织的核心业务流程相匹配,以便从核心业务流程中获取大数据治理的关键支持政策。主数据管理描述了一组规程、技术和解决方案,用于维护业务数据的一致性、完整性、相关性和精确性。大数据治理需要制订将大数据整合到主数据管理环境的政策。信息生命周期管理则要求组织判断应该将何种数据保留在数据分析系统,何种数据需要存档,何种数据需要删除。

    2、大数据治理成熟度评估

    等级

    等级描述

    初始级

    a.没有定义与数据治理相关的架构和角色;

    b.没有正式的数据治理策略;

    c.不具备数据治理能力。

    基本级

    a.定义了数据治理角色和职责,管理者意识到数据治理的重要性,但对管理知识知之甚少;

    b.已有的数据治理策略已经文件化,但不具有连贯性;

    c.数据治理能力十分有限,只有很少一部分人掌握数据治理通用级别的知识。

    定义级

    a.定义了数据治理角色和职责,管理者能主动推动数据治理计划实施;

    b.数据策略已经文件化,并涵盖了针对特殊数据的治理策略;策略通过公共渠道容易获取,大多数利益相关者能够理解;

    c.具备数据治理的全部要素,一部分人知道详细的数据治理能力。

    管理级

    a.定义了完备的数据治理角色和职责,并有专门的数据质量专家,管理者能主动推动数据治理计划实施;

    b.所有的数据策略都已经文件化,并且是审计合规的,都能通过公用渠道获取,数据治理利益相关者主动关注策略的增添、更新和删除;

    c.所有定义的数据治理能力层级都有可用的方法,建立了系统化的数据治理处理流程。

    优化级

    a.定义了完备的数据治理角色和职责,管理委员会来自各个部门,拥有元数据管理小组、数据质量技能中心、主数据管理委员会等;

    b.所有的数据策略都已经文件化,并且是审计合规的,所有的数据治理利益相关者都参与了策略发展过程;制订了自动化的政策,以保证数据在整个组织内保持一致、准确和可靠;

    c.所有定义的数据治理能力层级所指定的部门和关键数据是固定的,能够在数据处于静态和动态时进行数据质量修复,数据不间断地被跟踪检查,且任何偏离标准的问题都可以立即解决。

    成熟度评估是企业大数据治理状态和能力的一种衡量方式。大数据治理模型共三个维度,具体涵盖14个评价指标。每个指标分别以5个等级来衡量其成熟度,然后再统筹考虑评价指标权重,得到组织大数据治理的整体成熟度评价。根据综合评价结果,企业大数据治理成熟度可以分为以下5个等级,即初始级、基本级、定义级、管理级和优化级。

    四、企业大数据治理框架

    1、大数据治理总体框架

    根据企业大数据治理特点和需求分析,从企业大数据应用创新的角度,企业大数据治理总体框架由九部分组成。

    (1)大数据生命周期管理

    数据生命周期是数据治理的时间轴,数据治理服务于数据的全生命周期。因此,完善的数据生命周期管理是确保数据治理有序、全面的前提条件之一。在企业大数据领域,数据生命周期管理又分为两类,一类是技术层面的数据周期管理,指按照数据加工处理时序(数据采集、数据存储、数据处理、数据建模、数据调度、数据销存)而建立的时间里程管理;另一类是业务层面的数据周期管理,指按照业务流程时序而建立的时间里程管理。

    (2)数据源管理

    以数据资源目录的功能形式,提供对待治理的数据源的管理。在功能模块上,数据源管理由两类功能组成:一是数据源部门相关的组织机构管理功能,二是数据源的目录、格式类型和交互周期等资源属性管理功能。从数据源提供的数据类型上看,企业大数据治理的对象包括结构化数据、半结构化数据和非结构化数据,以及来自互联网的数据等。

    (3)主要技术支撑

    企业大数据治理中所用的主要技术包括数据检核引擎、ETL工具、消息中间件、流程引擎、Hive和MPPDB等。相对于传统数据治理技术,专门引入了Hive和MPPDB等大数据领域的数仓工具,代替传统数仓中Oracle、MySQL等关系型数据库,以满足大规模数据的治理效率要求。另外,要特别强调的是,数据质量检核引擎的设计最具技术含量,也最为重要,它直接决定了数据检核的能力和数据质量的把控程度。因此,质量检核引擎的设计要充分响应上文中的需求分析,体现技术先进性、功能完整性、覆盖全面性、检核深度性和使用便捷性,实现良好的数据质量检查和核对功能。

    (4)贴源层治理

    贴源层治理又叫近源治理,是指在最贴近数据源头的一侧,对数据进行建模、标准化和技术检核方面的治理。贴源层治理的要点如下:

    第一,数据建模时,须按照对业务属性的影响程度,区分主数据和业务数据,以满足数据实体在业务流程、数据质量控制方面的不同要求。主数据是指对业务影响至关重要的共享数据,如组织机构、员工、会计科目、物料、供应商、客户等。同时,也要按照记录属性对数据实体识别的影响,为每个属性设计权重,区分核心和普通属性,以满足深度数据质量控制要求。

    第二,数据标准化是指按照元数据或数据元标准规范,对汇集的源头数据进行格式转换、字典映射,进行初步的数据规范。

    第三,数据检核是数据质量控制的核心举措,根据是否存在业务相关性,又分为技术检核和业务检核。其中,数据技术检核是指对数据进行不涉及业务的检查和核对。即按照数据质量标准,使用数据检核引擎,对源数据进行格式、值域、重复度、完整性、准确性等质量校核,以最大程度地发现、排除问题数据,为后续质量控制打下坚实基础。

    第四,数据质量考核评价是贴源层治理的主要输出结果,通常这个结果以数据质量报告的形式输出。数据质量报告由标准规范体系中预先定义的质量评价指标组成,用于反馈数据治理相关方,触发数据质量控制的相关业务流程。

    (5)中心层治理

    与贴源层治理相对应的是中心层治理,即在贴源层治理和数据资源中心之外的其他治理内容。中心层治理的内容包括数据关联、数据融合和数据业务检核,它们具有一个业务相关的共性特征,即治理内容与数据所属业务领域密切相关。中心层治理的要点如下:

    第一,数据关联是指基于业务主数据,将各相关数据模型串联起来,形成实体的一个全息数据画像,并通过相关属性,将这种数据间的关联关系保存起来。数据关联对于企业大数据应用实施具有决定性作用,通常可关联的数据,才是实际可用的数据。

    第二,数据融合是指在数据关联的基础上,将同类数据去重后聚合,把“一数多源”变为“一数一源”;或者将同一个实体的不同数据片段,构建形成新的、更完整的数据描述。数据融合通常面向特定应用场景,是数据应用中最为常见的数据操作之一。

    第三,数据业务检核是基于数据的业务属性进行的业务逻辑合规性检查核对。业务检核是数据质量检核中不可或缺的部分,与技术检核同等重要。以个人身份证号数据为例,技术检核仅能做到身份证号长度、格式、特定位值(地区编码、年龄)等的合规检查,而不能识别该号码的真假;业务校核则是通过把该号码与身份证登记机关的数据库相比对,确认出号码的真假。

    (6)数据资源中心

    数据资源中心是数据治理的结尾环节,进入数据资源中心的数据被认为是标准、合规、正确、可直接应用的数据。在企业大数据治理体系中,数据资源中心阶段的数据治理,侧重于数据资产的形成和管理,以及数据集的存储划分。在该框架中,以数据资产目录来统领数据资产的管理;以面向数据实体的基础数据库和面向应用的主题数据库,统一存储治理后的数据。

    (7)数据标准规范体系

    数据标准规范是实施数据治理的基础前提条件,对数据治理的成效起着决定性作用。没有标准规范,无从数据治理;标准规范不全,数据治理不全。对于企业大数据来说,要做好治理需建立健全以下规范:

    第一,元数据标准。要全面建立元数据标准,做到对全域数据的覆盖。

    第二,数据元标准。要有选择地为主要数据实体建立数据元标准。

    第三,数据分类编码标准。要为重要数据建立分类编码标准,并为基础数据建立编码字典表。

    第四,数据目录规范。要在尽可能大的范围内,建立统一的企业数据资源目录规范,在最大程度上规范目录编码和操作。

    第五,数据质量标准。要从准确性、合规性、一致性、重复性、及时性、完整性等指标角度,建立全面的数据质量标准,并给出评估指标和评估方式。

    第六,数据治理流程规范。流程化是治理有序的保障,要将数据治理流程化,建立相应的流程规范,通过流程规范提升治理有序水平。

    (8)大数据安全和隐私管理

    企业的生产经营数据价值大、敏感度高,涉及企业战略的隐私和股东的权益。因此,在企业大数据的治理中,要建立相应的治理安全管理体系,确保各治理环节的数据安全。一般情况下,数据治理要达到以下安全保护要求:

    第一,按照《工业数据分类分级指南(试行)、《信息安全等级保护管理办法》和《信息系统安全等级保护定级指南》的要求,确定数据治理系统的安全保护等级,构建安全防护体系。

    第二,针对不同信息可动态设置安全保护手段。

    第三,治理功能与组织机构和用户分级权限相结合。

    第四,提供数据签名和数据脱敏功能,确保隐私安全。

    第五,所有治理操作均有记录日志,纳入统一安全审计管理。

    (9)其他方面

    为构建自动化、智能化的数据治理平台,企业大数据治理框架还需具有追溯和可视化展示功能。追溯功能是指设置并记录数据治理的各个里程节点,可以追查数据治理的过程信息。并且在一定时效和条件下,可将某节点治理后的数据回退到其之前的任何状态。追溯功能可实现数据治理的灵活控制,利于复杂数据环境下实现智能化数据治理。具有良好可视化展示功能是先进数据治理平台的基本要求。治理可视化能带来良好的用户操作体验,便于治理工作的实施,利于人工参与治理效率的提高。

    2、企业大数据治理主要流程

    企业大数据治理的主要流程如下图所示:

    第一,数据源分析。在新的数据源接入时,首先做数据源的分析,内容包括:确认要治理的数据类别、数据项和数据周期等,抽取样例数据,分析数据特征,做好为数据治理服务的规划准备。

    第二,数据治理规划。数据治理规划分为三个步骤:(一)对样例数据进行标准规范分析,根据分析结果得出数据模型和元数据标准;(二)对样例数据进行数据质量评估,根据评估结果制定数据检核规则、关联策略和融合方案;(三)将样例数据与其他已有数据进行对比,确定数据关联和融合策略,并进一步确认数据归属(所属的基础库或主题库)。

    第三,数据标准管理。根据数据治理规划的标准规范分析结果,建立全部数据模型,以及相关元数据、主数据或数据元标准,更新相关数据标准。

    第四,数据治理策略管理。根据数据质量评估和数据对比结果,确定数据检核规则,以及建立数据关联和数据融合的策略。

    第五,常态化数据治理实施。对待治理的数据进行数据检核、数据关联和数据融合,除初次治理的数据须经前四个步骤外,同类型数据后续进入常态化治理阶段,直接从本步骤开始。

    第六,数据资源管理。将治理后的数据存入基础库或主题库,从资产的属性对数据进行资产化处理,形成数据资产,进行数据资产管理。

    五、大数据时代企业数据治理策略

    1、建立完善的数据标准体系

    在大数据时代下,企业应该根据业务管理中所涉及的渠道、合约、产品、分类、事件等数据要素,逐步建立起机构标准类、员工标准类、产品标准类、客户标准类、渠道标准类、营销标准类、账户标准类、交易标准类、公共标准类以及合约标准类数据标准体系框架。同时伴随着大数据时代的不断发展,还要对该数据标准体系进行完善,从而更加规范、科学地指导企业使用数据。

    2、制定完善的数据应用标准流程

    数据标准的核心是建立一个统一的企业级规范,从而促进企业全行范围之内的数据有机共享,继而提升数据的管理和使用水平。尤其在大数据的时代下,企业更应该根据半结构化和结构化、非结构化数据的不同特征,基于加强内外部数据共享的角度为大数据制定统一的业务解释和标准,加强协调企业的相关部门对数据标准的不同需求,继而建立其适用的统一模型以及数据共享为基础的数据应用标准流程。

    3、形成完善的数据评估体系

    在大数据时代,企业更应该加强对数据一致性、完整性以及准确性的评估,继而保证数据的使用治理。也就是:(一)提供的信息不能存在着重复和冲突的现象,以保证数据的一致性;(二)必需的数据以及关联关系务必要存在,不能出现违反数据标准和质量需求的数据,体现数据的完整性;(三)数据务必能够反映出企业的真实信息,符合企业的实际业务需求,体现出准确性的特征。

    展开全文
  • 为深入实施国家技术创新工程,各级政府大力支持建设企业为主体、市场为导向、产学研相结合的技术创新体系,以提升企业自主创新能力和产业核心竞争力。科技部印发了《关于推动产业技术创新战略联盟构建与发展的实施...
  • 技术运营体系

    千次阅读 2019-11-24 20:47:13
    通道培养体系建设 职业等级评定 职业规划管理 发展活动组织 腾讯技术运营级别 运营管理部 监督公司所有正在运营产品的投入和产出,\n运营状况,向管理层提供战略汇报与建议 BG(事业群)运营...

    在这里插入图片描述

    技术运营体系
    	概念
    		诞生背景
    			技术运营诞生于腾讯大规模业务 技术支持与产品运营 过程中逐步演进而产生的
    		是什么
    			技术运营以企业产品或业务投入产出比为核心关注点,并围绕此关注点开展一系列\n的解决方案。技术运营的目的是为了优化企业资源,提升用户价值
    		价值
    			极致的产品体验: 技术运营抓业务场景,分析细节,针对细节全方位分析
    			业务快速发展且成本可控:对业务场景全方位分析,精细化运营,可以实现\n优化业务,带来良好的用户体验和成本控制
    			工匠精神:工匠精神是精细化技术运营的灵魂,精细化技术运营注重细节,\n是对技术细节的深挖,对运维价值的创新
    	范畴
    		资源维度:目标成本优化与管控
    			 资源规划:技术运营战略性与纲要性方向,面向业务,技术运营载体
    			预核算: 业务资源与成本管控,度量,技术运营效率考量的依据之一
    			资源容量与供应:资源随着业务声明周期进行波动,高效适配资源,提升供应效率
    		业务维度:目标是提升业务运营水准与效率
    			产品体验与运营优化:产品运营数据分析(运营质量数据,业务指标数据,资源数据)
    			技术架构评审:全方位观察产品或业务,抓细节;系统优化,架构升级,算法调整,产品策略,资源适配等
    			运营项目管理:以项目方式推进技术运营的落地
    	组织体系
    		职业发展通道
    			通道培养体系建设
    			职业等级评定
    			职业规划管理
    			发展活动组织
    		腾讯技术运营级别
    			运营管理部
    				监督公司所有正在运营产品的投入和产出,\n运营状况,向管理层提供战略汇报与建议
    			BG(事业群)运营部
    				负责本事业群业务的技术运营,包括业务运维,\n资源运营,产品体验与运营优化,\n运营项目管理;是技术运营的主要实施者
    		岗位细分
    			运营规划
    			系统技术
    			网络技术
    			数据中心技术
    			DBA
    			业务运维
    			服务管理
    		能力方向
    			通用能力
    			专业知识
    			专业技能
    			组织影响力
    		运营流程与规范
    			公司层面流程规范:覆盖面广,通用性强,重资产运营
    			事业群层面流程规范:具有很强的专业性,重场景,重实操
    		奖励与惩罚
    			奖励
    				谁提出,谁来做,独立成军
    				对标,树立标杆,进行奖项激励
    			惩罚
    				以用户价值影响程度做主要参考
    	运营支持
    		数据支持
    			作用:用数据来说明,验证,体现优化前后效果,质量差异等
    			数据的定义:被解释的数据才能成为有价值的信息
    			数据的采集
    				宜早不宜晚
    				宜全不宜少
    			数据的类型
    				行为数据:通过用户画像,描述用户在站点的操作轨迹
    				业务数据:订单,用户,评价,商品信息等
    				资源成本数据:资源数据与运营成本等
    				流量数据:流量来源,流量构成
    				外部数据:舆情分析,竞品爬虫等
    			数据的分析:解析数据内涵,转化为信息
    		工具或系统支持
    			工作或系统支持用于固化技术运营的工作行为与标准,让后来者再次基础上,\n持续提出优化与改进,让技术运营能力与水平的提升持久延续
    			用小工具解决技术运营中的杂活,小工具的制造应该是低成本的
    			技术运营提倡工具文化
    		以业务为导向的服务提升
    			技术运营后期需要转向以业务为导向进行服务提升,表面在四个方面
    				质量
    				效率
    				成本
    				安全
    				补充:参考海量运维,运营规划
    	精细化技术运营
    		介绍
    			精细化技术运营主要在产品成长期启动,在成熟期持续加大力度,以尽可能延长产品的成熟生命期
    		运营效率监控
    			资源运营基础数据
    				范围:服务器利用率,带宽使用监控,专线使用监控
    				方法:采集指标数据汇总分析得出结论
    				结论:达标,不达标,低负载,连续低负载,空负载,连续空负载
    			业务运营数据
    				范围:业务逻辑在http层,RPC层产生的数据
    				方法:业务运营分析方法:1.确定分析模型;2.收集数据;3.汇总分析;4.得出主要结论;5.输出报告
    				结论:形成评估新业务模块健康状况
    			总结:运营效率监控是为精细化技术运营提供方向和效果检验
    		技术架构评审
    			介绍
    				要实现精细化技术运营,需要从技术架构入手,从框架逻辑,算法实现,产品策略等多个方向不断审视与优化
    			技术架构与运营效率关系
    				技术结构决定业务运营效率
    			纵横类比法
    				纵比:结合业务运营数据分析结果,同一产品升级前后业务运营数据比对
    				横比:结合业务运营数据分析结果,不同产品之间进行技术架构对比
    				类比:结合业务运营数据分析结果,同类型竞品之间进行技术架构对比
    			架构资源模型法
    				拆细业务:用户视角根据将业务场景拆细
    				模块资源模型:得到模块,资源,业务指标之间的关系
    			总结:技术架构评审是精细化技术运营的手段;产品体验优化,用户价值提升,成本优化控制则是精细化技术运营的目的
    		方法论
    			理清构成:纵向切分,模块级别
    			抓大放小:精力有限,解决主要矛盾
    			庖丁解牛:技术架构,算法实现
    			双管齐下:技术优化,产品策略优化
    			持之以恒:一切都是动态的,优化无止境,做到极致
    	补充
    		如何落地技术运营
    			目标导向,跨部门协同推进,阶段性,场景驱动,项目落地
    		什么样的企业环境适合推广技术运营
    			整个知识体系提供了2个维度,7个方向。企业存在下列任意情况时,可以尝试有选择性的推广落地
    				业务或产品处于快速发展阶段,技术人员只关注功能实现而缺少成本把控
    				业务或产品处于成熟期或衰退期,而成本未缩减,反而增加
    				业务或产品数量众多,现有的组织结构中没有专门负责资源运营的部门
    				感受到业务或产品投入产出比失衡严重
    		如何检验技术运营处于哪个阶段,下一步指导方向
    			参考技术运营能力成熟度模型
    
    

    未完,持续更新中…

    展开全文
  • 本文将企业的架构进行全方面的梳理,并给出云原生体系建设总图,这个图当然不是一蹴而就就能建设完毕的,而是根据业务需求不断迭代演进出来的,但是我们要知道目标在哪里。

    本文转载自【刘超的通俗云计算】公众号,作者刘超,网易杭州研究院云计算架构师

    上文:以业务为核心的云原生体系建设(上)

    4、云原生体系演进阶段二:构建中台体系,加速业务创新

    上一节,我们讲了阶段一的很多问题,其实这些问题归根结底是一个字——散。系统散,数据散,流程散,组织散,而当前的市场竞争条件下,业务创新要争分夺秒,如此“散”的架构没有办法拧成一股绳,应对业务的快速变化,就像集团军作战,各个部队分兵作战,就不能形成合力。

    因而要将这些系统,数据,流程,组织重新组合,形成公司的“腰部力量”,强调能力的沉淀,强调融合与复用。只有有了“腰部力量”,才能灵活应对业务的快速变化,这就像打篮球,“腰部力量”是最重要的,无论是投三分球,还是在空中做花哨的投篮动作,看起来是在手腕,其实真正的能力在腰部。

    这就是我们常说的中台。中台这个词很火,有的人觉得很好,有的人觉得太虚,但是名字无所谓,其实就是构建公司的可复用能力。

    4.1、中台的定义

    这里给中台下一个相对完整而准确的定义。

            

    这个概念需要解读一下。中台是为了体现IT技术,IT系统,IT部门的业务价值而诞生的概念。这一点如果作为一个纯技术,很难感受到这一点,感觉中台就是忽悠,如果在一家技术为主导的公司也很难感受到这一点,觉得技术的价值马老板都清清楚楚,还需要“体现”吗?

    但是在传统企业,可不像互联网公司这样重视技术,业务部门的老大在中国的市场经济搏杀了几十年,最后混出来靠的一个是中国过去几十年的快速发展及人口的红利,二是老板们对于市场,营销,供应链的把控。当然这种野蛮生长的过程,并没有对IT技术和IT系统有什么感觉,所以往往会重业务而轻技术,重硬件而轻软件。当然低成本人口红利的野蛮生长阶段已经过去,老板们也发现过去的这一套有点玩不转了,差异化客户体验驱动产品创新阶段已经到了,他们开始眼红互联网公司的兴起了,于是开始设立了CIO这个职责。只不过大部分公司的情况是,CIO作为高管,在业务老大那里话语权还不高,毕竟钱是业务部门赚的,真正IT预算都是业务老大要批的,所以在传统企业,能够体现业务价值非常重要,这是中台这个词的核心,也即定义中的“面向业务场景”以及“支撑业务快速迭代”所强调的,CIO要让CEO,业务部门理解IT部门和IT系统的价值。

    4.2、中台的误区

    之所以对于中台的定义这么复杂,另外一个问题就是,大家对于中台的理解经常出现错误,最终导致企业构建中台不正确,却怪中台太虚,不落地。

    这里总结了中台五大误区。

    4.2.1、误区一:中台构建的太早

    中台是企业已有系统积淀,解决了业务温饱问题,要进一步解决业务创新问题时候用的。

    如果你是一家创业公司,那解决温饱问题,确定业务模式最为重要,如果这个时候花大量的时间建设中台,一是你本来就没什么可沉淀的,二是沉淀了也可能因为创业方向变化而白沉淀,三是过于重视技术耽误了你取得业务成功的时间。

    其实大家只要看看阿里什么时候搞的中台,就明白了。中台要有共性,淘宝,天猫,聚划算,1688都是电商业务。中台要先在一个业务取得成功,淘宝2003年创立,天猫创立较晚,两者时间差比较大,淘宝的系统才能演进为中台。

    4.2.2、误区二:对中台期望太高

    中台可能被吹的太牛,有时候被当成了万金油,似乎什么都能解决。例如中台能够使业务创新这件事情,就属于期待过高。

    中台没有办法让业务创新,只能“支撑”业务创新,说白了就是中台其实就是可复用能力,这种能力是一种内功,是一种支撑能力,但是替代不了业务能力。

    如果业务方自己想不出业务创新的方法,或者不愿意想业务创新的方法,只想吃老本,那中台帮不上任何忙。但是如果业务方能够想出50种(约数)创新的方法,但是不知道哪个对的时候,中台的可复用能力就帮上忙了,其中业务中台可以使得业务方在这50个方法里面快速的尝试,而数据中台使得业务方能够快速看到这些方法的尝试结果,这样就能快速找到业务突破的方向。

    4.2.3、误区三:觉得中台太简单

    以为中台就是现有系统的接口组合,以为通过ESB将服务编排一下就解决了。将ERP,CRM等后台系统通过ESB暴露出去不是中台。

    第一个原因是,CRM里面有客户,而手机APP里面的用户中心也是客户,但是两者有明显的区别,CRM里面是后台管理语言,是给公司内部的人看的,也是按照公司内部的人管理最方便的方式组合信息的,他不是前台业务语言,从后台的CRM到APP上的用户中心中间还有一定距离。

    这里常见的例子是,有的银行的App比较难用,而支付宝和微信支付就对用户友好,有的航班的App比较难用,而航旅纵横就对用户友好,如果仔细观察,你能发现其中的区别吗,很多银行的App将柜员系统中的概念和操作方式直接搬到了App上,很多航班将柜台系统中的概念和操作方式也是直接搬到了App上。

    第二个原因就是上面说过的,单体应用群通过ESB暴露出去,虽可以实现信息拉通,但是无法达到中台快速迭代的目标。

    4.2.4、误区四:觉得中台太复杂

    很多传统企业一听中台,就觉得一下子要上N各系统,将原来的服务拆分的七零八落的,然后看看自己手里就这几十号人,应该搞不定,于是望而却步,任务中台太复杂,这是互联网公司的事情,传统企业不应该参与。

    其实这是误解,中台的构建有两种方式,封装式和重构式,传统企业往往害怕的是重构式,然而其实中台的建设有渐进的过程,可以保留原来的系统,通过逐渐的封装,构建自己的中台。

    4.2.5、误区五:觉得中台太技术

    有的企业比较有钱,觉得中台的构建就是个技术问题,只要花钱买一个一线互联网公司的大平台就搞定了中台,这也是一个很大的误区,因为你没有自己的架构师团队和中台团队,没有自己的流程和规范,没有自己沉淀可复用能力的方法论,还是没办法应对业务的快速迭代。这就像你在健身房看到一个健身教练用一个很牛的器械练了六块腹肌,你就把器械买来,自己不练,那也没有腰部力量呀。

    4.3、中台建设的两种方式

    4.3.1、封装式

    传统企业由于采购大量传统服务,可采用封装式构建中台。

    前台APP或者门户一旦需求改变,后台采购系统或核心稳态系统不可能随之改变,所以中间封装中台服务层

    传统服务多使用SOAP协议暴露接口,可通过ESB或者API网关转换为RESTFul接口对上暴露

    服务层采用最新微服务架构进行开发,适应前台快速迭代

    4.3.2、重构式

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    互联网公司历史包袱轻,大型银行,运营商等由于技术力量充足,可对于部分系统进行全方位的重构为微服务架构,并以此为底座构建中台,可全面实现自主可控,和快速迭代。

    4.4、中台如何解决第一阶段的问题

    接下来,我们来看中台如何解决第一阶段的问题,我们还是从企业架构的五个方面逐个分析。

    4.4.1、业务架构:架构服务化,侧重变化多和复用性,领域拆分与解耦       

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

     

    上一节,我们讲了影响快速迭代的问题是架构腐化问题,那如何解决这个问题呢?就是通过服务化的方式,将不同的业务领域拆分到不同的工程里面去。

    这样第一会增加可理解性,工程更加的简洁,每个工程只做一个领域的事情,职责单一,这样就会既容易修改,也容易Review。其实按照人性角度来讲,易Review更加重要,因为拆分后的服务虽然聚焦于某个领域,也会腐化,易Review能够早日发现腐化,早日修复。

    第二会增加可测试性,越是耦合在一起的庞大代码,测试覆盖率越低,越容易出现问题,而拆分后的服务测试更加容易展开,覆盖率变高。测试覆盖率是验证架构有没有腐化的指标,也是领导或者架构委员会能够看到的,也有利于及时制止和修复腐化。

    第三,也即最重要的就是可观测性,服务化之后,一般要有服务统一的注册发现和接口管理平台,通过这个平台,服务之间的调用关系以及接口的设计和文档,领导和架构委员会都能看到。

    调用关系变乱是架构腐化的重要指标,服务之间的调用应该分层单向调用,严禁循环调用的,如果多个服务之间的调用一团乱麻,那就说明腐化了,应该及时制止和修复。另外接口不符合规范,也是架构腐化的重要指标,接口如果开始出现模糊,或者传入大量的参数,甚至传入Hashmap将参数通过key-value的方式传递,那就说明里面的架构已经腐化了,应及时制止和修复。

    这样就是实现了架构始终保持在轻债务的阶段,这样开发敢改,同事容易Review,QA容易测试,领导和架构委员会也看得到的效果。

    而且服务化拆分后,会将很多内部的功能,暴露成接口对外提供服务,并且接口经过Review和设计,而且文档和调用方式都在注册中心上,非常方便其他服务调用,从而实现可复用性。

    从而最终实现了快速迭代。

    你可能会问,你说了半天服务化,和前面的中台啥关系呢?中台这个词其实是给业务方听的,具体到技术手段,就是服务化。作为技术部门,需求都是从业务方来的,业务方其实不关心我们拆了多少服务,就是希望能够快速完成需求,而服务化就是为了完成这个目标的,只不过你说服务化,甚至拆分啊,架构啊,业务领导听不懂,所以就说为了更快响应他们的需求,给他们建设了中台。

    那服务化应该从哪里开始呢?

    这里很多技术人员都会犯的错误是,从数据库出发,看数据库结构如何设计的,按照数据库最容易拆分的方式进行拆分。这样是不对的,没有站在业务的角度去考虑问题。应该借鉴领域驱动设计的思路,从业务流程的梳理和业务领域的划分出发,来划分不同的服务,虽然最后映射到数据库可能会拆分的比较难受,但是方向是对的,只有这样才能适应未来业务的快速变化,起到中台应该起到的作用。我个人认为,方向比手段要重要,方向对,当前痛一点没什么,但是当前不痛,方向错了,还是解决不了问题。

    当然领域驱动设计在落地的过程中可能存在各种问题,比如前期规划时间过长,前期设计阶段考虑不到细节的场景,落地的时候会经常碰到和前期设计不一致的地方,需要返工等现象。其实互联网公司也大多没有安装领域驱动设计的完整流程来做,但是这里面的流程梳理和领域划分,还是很必要的。

    领域划分好了,接下来就要开始拆分出服务,进行服务化了。从哪里入手呢?比较落地的方法是随着新需求的不断到来,渐进的进行拆分,而变化多,复用性是两大考虑要素。

    这么说有点虚,我们举个现实的例子。例如按照领域的划分,对于电商业务来讲,一个单体的Online服务,应该拆分成下面这些服务。

           

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    但是绝不是发起一项运动,闭门三个月,一下子都拆分出来,一方面没有相应的工具链,流程,员工的能力的适配,将使得服务化失控,这也是我们经常观察到,很多企业服务化之后,一下子失控,从而不断的加班,业务SLA降低,需求接的更慢了等现象,然后就放弃了服务化,回归单体应用,然后骂中台,微服务是垃圾。

    领域驱动设计的结果仅仅是一个规划,使得后台的技术人员在和业务的领域专家讨论业务流程和场景的时候,对于业务有更深入的理解,并且通过DDD的输出有一个完整的地图。但是接下来后台技术部门不应该闷头开始就按这个拆了。因为领域知识从业务部门到技术部门的传递一定有信息的丢失,这也是DDD落地被诟病的地方,就是业务方规划的时候是这样说的,落地来需求的时候,却是另外一种说法,导致根据DDD落地好的领域,接需求接的更加困难了。

    所以赵本山说,不看广告,看疗效。对于服务拆分,DDD是一个完整的地图,但是具体怎么走,要不要调整,需要随着新需求的不断到来,渐进的进行拆分,DDD领域设计的时候,业务方会说不清,但是真的需求来的时候,却是实实在在的,甚至接口和原型都能做出来跟业务看。

    需求到来的时候,技术部门是能感受到上一节讲过的架构耦合导致的两个现象:

    • 耦合现象一:你改代码,你要上线,要我配合

    • 耦合现象二:明明有某个功能,却拿不出来

    第一个现象就是变化多,在业务的某个阶段,有的领域的确比其他的领域有更多的变化,如果耦合在一起,上线,稳定性都会相互影响。例如图中,供应链越来越多,活动方式越来越多,物流越来越多,如果都耦合在Online里面,每对接一家物流公司,都会影响下单,那太恐怖了。

    第二个现象就是可复用,例如用户中心和认证中心,根本整个公司应该只有一套。

    在《重构:改善代码的既有设计》有一个三次法则——事不过三,三则重构。       

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

     

    这个原则也可以用作服务化上,也即当物流模块的负责人发现自己接到第三家物流公司的时候,应该就考虑要从Online中拆分出来了。另外就是,当有一个功能,领导或者业务方发现明明有,还需要再做一遍,这种现象出现第三次的时候,就应该拆分出来作为一个独立的服务了。

    这种根据业务需求逐渐拆分的过程,会使得系统的修改一定是能够帮助到业务方的,同时系统处在一种可控的状态,随着工具链,流程、团队、员工能力的增强慢慢匹配到服务化的状态。

    这个阶段服务化的结果如下图所示。

                 

     

    4.4.2、技术架构:基础设施云化,统一接口,抽象概念,租户自助

    服务化的过程,工具链很重要,技术架构就是解决这个问题的。

                 

    经过业务层的的服务化,也对运维组造成了压力。

    应用逐渐拆分,服务数量增多。随着服务的拆分,不同的业务开发组会接到不同的需求,并行开发功能增多,发布频繁,会造成测试环境,生产环境更加频繁的部署。而频繁的部署,就需要频繁创建和删除虚拟机。如果还是采用上面审批的模式,运维部就会成为瓶颈,要不就是影响开发进度,要不就是被各种部署累死。

    这就需要进行运维模式的改变,也即基础设施层云化。

    虚拟化到云化有什么不一样呢?云计算带来的改变,统一接口,抽象概念,租户自助。

    首先是接口统一,例如基于OpenStack实现,大部分部署工具支持其接口,可基于开源工具实现发布的工具化和平台化。

    其次是概念的抽象。

    原来出现服务器机型碎片化,资源分配碎片化的现象。Flavor抽象资源配比(4G 8G 计算优化型,网络优化型,存储优化型),统一硬件配置,提升利用率,硬件上线效率提升。

    VPC屏蔽物理网络复杂性,冲突问题和安全问题,使得租户可自行配置网络。原来的网络使用的都是物理网络,问题在于物理网络是所有部门共享的,没办法交给一个业务部门自由的配置和使用。因而要有VPC虚拟网络的概念,每个租户可以随意配置自己的子网,路由表,和外网的连接等,不同的租户的网段可以冲突,互不影响,租户可以根据自己的需要,随意的在界面上,用软件的方式做网络规划。

    其三是租户自助。

    也即人工创建,人工调度,人工配置的集中管理模式已经成为瓶颈,应该变为租户自助的管理,机器自动的调度,自动的配置。

    自动调度代替人工调度,区域可用区抽象对机房机架交换机的感知。

    云提供租户概念,有账号子账号体系,有quota,可以让租户在管理员许可的范围内自助操作,加快环境部署速度。

    4.4.3、数据架构:统一指标体系,建设数据仓库,支撑管理决策

    服务化之后,各个系统的业务数据格式统一了,制定了统一标准,并且上游系统设计的时候会考虑到下游的使用,下游系统设计的时候,会考虑到和上游兼容,统一的客户ID,订单ID等能够将整个业务流程串起来,有利于建设统一的指标体系。

    有了这个基础,就可以建设统一的数据仓库了。数据仓库的构建不能像第一阶段一样再数据库里面,或者业务系统里面直接进行分析,需要通过数据接入,将数据抽取出来,经过一定的处理,放到数据仓库里面来。       

    640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

    这就需要建设大数据的技术平台。

    第一个步骤叫数据的收集。数据的收集有两个方式,第一个方式是拿,专业点的说法叫抓取或者爬取,例如Nutch就是这样爬取全网的数据的,建设数据中台,你需要融合外部数据,为经营做决策,就需要通过爬取的方式。另外一个方式就是推送,有很多终端可以帮我收集数据,比如硬件终端的推送,应用系统的埋点等,这些是融合内部数据。还有数据是从数据库里面抽取出来的,就要用到DataX等数据交换工具。

    第二个步骤是数据的传输。一般会通过队列方式进行,因为数据量实在是太大了,数据必须经过处理才会有用,可是系统处理不过来,只好排好队,慢慢的处理。例如Kafka就是常用的队列,有时候传输的过程中要对数据做预处理,这就是常说的ETL,Extract-Load-Transform。

    第三个步骤是数据的存储。存储的数据量比较大,需要使用大容量的存储,可以使用分布式文件系统 HDFS,对象存储OSS,以及Hbase, MongoDB等NoSql的数据库。

    第四个步骤是数据的处理和分析。这里主要分离线处理,例如Map-Reduce, Hive, Spark,也有实时流处理,例如Flink, Spark Streaming, Storm等。

    第五个步骤就是对于数据的检索和挖掘。检索多用ElasticSearch,可以做即席分析,例如Kylin, Impala, ClickHouse, Hawk,也会有一些算法可以进行数据挖掘,例如Spark ML里面的分类,聚类等。

    数据平台的建设,还只是建设了一个技术平台,作为中台,还应该有业务属性,也即数据仓库,也即从业务领域的角度建立一些表,方便进行业务角度的分析。

    咱们前面服务化的时候,梳理了业务领域的划分以及业务流程,这在数仓建设中也是很有用的。如图所示,里面有商品域,采购域,物流域,交易域,这些都是和服务相对应的。我们建设数仓的时候,里面的指标设计也是按照业务流程来的,这也是和服务相对应的。

    当基于业务领域划分和业务流程梳理,总结出来的数据仓库及指标,是能够反映业务的运行过程的,在此之上,建设BI报表,和领导驾驶舱,可以将原来以周为单位的经营情况反馈过程,缩短到天甚至小时。

           

    这里面有一个制造业的例子,就是经过数仓的建设和指标的梳理,已经可以很好的做业务运营监控了。

                 

    4.4.4、研发流程:发布模式平台化,构建持续集成流程,质量和绩效看板

    我们再来看研发流程,云平台的建设提供了统一的接口,这使得发布模式可以更容易的对接资源,实现平台化,并基于平台构建持续集成流程。

    因为如果云计算不管应用,一旦出现扩容,或者自动部署的需求,云平台创建出来的虚拟机还是空的,需要运维手动上去部署,根本忙不过来。因而云平台,也一定要管理应用。基于云计算OpenStack的虚拟机分层镜像发布和回滚机制,构建发布平台,可实现大规模批量部署和弹性伸缩。

    基于虚拟机的PaaS托管中间件,简化租户创建,运维,调优中间件的难度。云平台的PaaS负责创建的中间件的稳定,保证SLA,当出现问题的时候,会自动修复,从而业务方不用管PaaS中间件的部署和SLA了。

    发布平台提供基于虚拟机镜像+PaaS中间件,做完整的应用的部署和上线,称为编排。基于编排,就可以进行很好的持续集成,例如每天晚上,自动部署一套环境,进行回归测试,从而保证修改的正确性。

    要求业务对于高可用性设计要在应用层完成,而不能完全依赖于基础设施层的能力了。每一个服务都有实现良好的无状态化处理,幂等服务接口设计。每个服务都要设计有效探活接口,以便健康检查感知到服务状态。通过制定良好的代码检查规范和静态扫描工具,最大化限制因为代码问题造成的系统不可用。

    4.4.5、组织架构:成立中台组/架构师组,衔接研发和运维

    上面的技术问题说完了,接下来说一说组织问题,根据康威定理,组织方面就需要有一定的调整。

    上面说过,中台是为了能够集团军作战,能够协调各种力量为业务快速迭代服务,要建设腰部力量,除了上面所说的各种系统,人当然是最重要的,人不能调度起来,系统建设的再好也白搭。

    所以不能再运维组和开发组隔离了,而要成立架构师组,或者就像前面图中的架构委员会,当然这个架构组一开始试点不用很大,试点阶段一定要有这个角色,来横向协调各种资源,并且挂在CIO下面,有一定的话语权。

    这就是前面总图里面,我把架构委员会叫做军机处的原因,军机处当时就是为了打仗调动资源设置的机构,直接向皇帝负责,虽然下面的六部都不直接汇报给军机处,但是军机处作为皇帝的辅助大脑,可以监视整个架构的情况。另外一个比较好的比喻就是政委,在架构委员会里面有各个组的代表,所以指定流程的时候,各个组的意见也会参考,架构委员会制定的流程,各个组的代表有责任将流程贯彻下去,这就相当于军队里面政委的作用,我党的军队如此有战斗力,和政委的存在以及贯彻党的思想十分密切。

    应该建立独立的前端组,统一前端框架,界面一致,所有人掌握统一的前端开发能力,积累前端代码,在有新的需求的时候,能够快速的进行开发。

    建立中间件组,这部分人不用贴近业务开发,每天的任务就是研究如何使用这些中间件,如何调优,遇到问题如何Debug,形成知识积累。如果有统一的一帮人专注中间件,就可以根据自身的情况,选择有限几个中间件集中研究,限定业务组只使用这些中间件,可保证选型的一致性,如果中间件被这个组统一维护,也可以提供可靠的SLA给业务方。

    将业务开发组分出一部分来,建立中台组,将可以复用的能力和代码,交由这几个组开发出服务来,给业务组使用,这样数据模型会统一,业务开发的时候,首先先看看有哪些现成的服务可以使用,不用全部从零开发,也会提高开发效率。

    4.5、阶段二的问题

    其实大部分的企业,到了这个阶段,已经可以解决大部分的问题了。能够做到架构服务化,基础设施云化的公司已经是传统行业在信息化领域的佼佼者了。中台开发组基本能够解决中台的能力复用问题,持续集成也基本跑起来了,使得业务开发组的迭代速度明显加快。集中的中间件组或者架构组,可以集中选型,维护,研究消息队列,缓存等中间件。在这个阶段,由于业务的稳定性要求,很多公司还是会采用Oracle商用数据库,也没有什么问题。

    实现到了阶段二,在同行业内,已经有一定的竞争优势了。

    那什么情况下才会觉得阶段二有问题呢?

    我们发现,当传统行业不再满足于在本行业的领先地位,希望能够对接到互联网业务的时候,上面的模式才出现新的痛点。

    对接互联网所面临的最大的问题,就是巨大的用户量所带来的请求量和数据量,会是原来的N倍,能不能撑得住,大家都心里没底。

    例如有的客户推出互联网理财秒杀抢购,原来的架构无法承载近百倍的瞬间流量。

    有的客户对接了互联网支付,甚至对接了国内最大的外卖平台,而原来的ESB总线,就算扩容到最大规模(13个节点),也可能撑不住。

    有的客户虽然已经用了Dubbo实现了服务化,但是没有熔断,限流,降级的服务治理策略,有可能一个请求慢,高峰期波及一大片,或者请求全部接进来,最后都撑不住而挂一片。

    有的客户希望实现工业互连网平台,可是接入的数据量动辄PB级别,如果扛的住是一个很大的问题。

    有的客户起初使用开源的缓存和消息队列,分布式数据库,但是读写频率到了一定的程度,就会出现各种奇奇怪怪的问题,不知道应该如何调优。

    有的客户发现,一旦到了互联网大促级别,Oracle数据库是肯定扛不住的,需要从Oracle迁移到DDB分布式数据库,可是怎么个迁移法,如何平滑过渡,心里没底。

    有的客户服务拆分之后,原来原子化的操作分成了两个服务调用,如何仍然保持原子化,要不全部成功,要不全部失败,需要分布式事务,虽然业内有大量的分布式方案,但是能够承载高并发支付的框架还没有。

    当出现这些问题的时候,才应该考虑进入第三个阶段,微服务化。

    下一节,我们来看阶段三如何解决这些问题。

    未完待续


    作者简介:刘超,网易杭州研究院云计算技术部首席架构师,出版《Lucene应用开发解密》,极客时间专栏《趣谈网络协议》《趣谈Linux操作系统》,毕业于上海交通大学,曾经就职于EMC,CCTV证券资讯频道,HP,华为等,目前在网易从事容器,Kubernetes和微服务的架构工作。长期致力于云计算开源技术的分享,布道和落地,将网易内部最佳实践服务客户与行业。个人公众号《刘超的通俗云计算》发表OpenStack, Kubernetes, 微服务类技术文章107篇,其中《终于有人把云计算,大数据,人工智能讲明白了》累积10万+。

    展开全文
  • 创新体系建设逐渐成为经济体制改革的主题之一,当前,各地都不断深化完善创新体系建设,提高自主创新能力,使得创新体系建设不断地获得新成效。“深港技术创新大赛”的举办对于丰富创新体系,搭建开放式创新网络,...
  • 技术管理的维度

    千次阅读 2019-08-02 10:47:03
    技术管理无疑是一项综合性工作,包含业务、技术和管理这三大维度。如何把这三大维度通过一定的方式展示给开发人员,从而让开发人员能够快速和准确的理解进而完成转型是我们首先需要明确的一个核心问题。针对该问题,...
  • 如何搭建企业数据化运营体系

    千次阅读 2019-07-10 14:59:56
    分享内容包括两个方面:一个是数据化运营的战略意义,另外一个是如何去建设数据化运营的体系。 一、为什么要做数据化运营? 数据化运营更多时候是用来辅助决策的,而从常规企业决策路径中可以看到,从发现问题、确定...
  • “工业互联网+智慧安全+环境保护”的危化企业双重预防机制数字化建设综合解决方案。以落实集团企业责任目标为导向,以标准化要素管理为依托,抓住风险管控和隐患排查治理这条业务主线,实现覆盖公司、基层单位,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 47,611
精华内容 19,044
热门标签
关键字:

企业技术创新体系建设