智能运行与维护 - 智能运行与维护应用实践(试用版)
点击免费下载《应用智能运维实践(试读版)》https://developer.aliyun.com/topic/download?id=1193
本章内容简介
智能化是未来企业IT运维的主要趋势。本章综述了通过算法替代人工发现、定位、处理风险,为IT运维提供决策支持的相关技术和产品的演进脉络,介绍了IT运维分析、事件关联分析、自动化运维、人工智能运维和开发运维一体化几个具有普遍认知的相关理念的发展历史及实际应用价值,总结了智能运维技术和产品的发展对企业应用运维管理的推动作用。
2.1 初识智能运维
近几年,人工智能技术发展很快,通常理解的智能运维是把人工智能技术应用在IT运维领域,替代人工进行风险管理决策。从通过机器实现自动化流程、替代人工并解放运维人员的根本需求出发,能替代人脑进行运维决策、人手管理配置的算法和工具都可以称为智能运维系统。2000年,早期机器学习算法出现,用来代替人脑识别指标的变化模式,预测未来的趋势。IT运维管理通过程序实现软件、硬件的自动管理,这已经是智能运维的初级阶段。未来,智能运维技术借助概率计算、深度神经网络、因果推理分析等高级人工智能算法,将进一步提升系统自主分析决策能力,实现自治程度更高的智能运维。
2.2 智能运维,赋予企业运维更强悍的大脑
数字化新术、新需求的涌现促使企业拥有的应用规模和应用复杂度快速膨胀,使得企业应用运维不堪重负。由于应用性能问题导致企业用户流失和经济损失的案例逐渐增加。传统IT运维的被动响应式风险处理机制已难以应对这些问题。实现主动预防的风险处理机制已逐渐成为构建面向未来的智能运维平台的关键。
为应对未来将面临的智能、互联时代的运维挑战,通过机器智能手段处理机器数据、解决机器系统的复杂度膨胀问题,是目前唯一可行的解决方案。搭建智能运维平台,构建高效、智能的应用性能风险主动防御体系,可以让企业变被动为主动,防患于未然。
《纽约时报》一篇文章曾报道,微软研究人员Harry Shum发现:当网站的响应时间比竞争对手慢250ms以上时,用户更倾向于关闭网站。这说明应用软件的用户体验下降或宕机将直接导致用户流失,当前企业经营运转比以往更依赖应用软件。除此之外,近年来新技术、新需求的涌现促使企业拥有的应用规模和复杂度快速膨胀,企业原有的IT运维逐渐无力招架,应用性能异常导致的用户流失和经济损失的问题更加突出。
目前,尽管已有很多企业认识到应用性能问题的严重性,并已加大投入来构建、完善应用性能管理平台,然而,传统应用性能管理主要以实时监控、被动告警方式通知运维人员处理风险。这种方式虽然能降低损失,但无论运维人员反应多么迅速,其仍需要耗费少则几小时,多则几天时间来排查解决故障,因此这种方式无法避免对企业运营造成的影响。阿里云、WhatsApp、Adobe Creative Cloud、Facebook等频繁发生的事故时刻提醒我们问题的严重性。因此,被动处理方式的APM已不能满足企业快速数字化转型的需要,主动分析定位潜在问题、预防应用性能风险已成为未来APM的趋势。如何做到主动防御,提前发现并规避风险呢?
红木神经科学研究院创始人、美国工程院院士杰夫·霍金斯认为:智能的本质是“预测”。只有能够预测未来趋势和可能发生的事件,才能争取提前规避问题的时间,这是变被动为主动的关键。因此,APM只有具备了对未来应用性能变化趋势及风险的“预测能力”,才能主动发现并规避风险,将企业运维人员从繁冗的应用性能管理工作中真正解脱出来。
分析海量历史运维数据是在应用健康状态良好的情况下提前发现风险的主要途径。从数据中找到应用存在的潜在问题与风险,可主动预防应用性能风险。现阶段,APM预测分析能力对用户的价值主要体现在以下几个方面:①预测未来应用性能的变化趋势;②实现更精准的容量规划;③预测、分析应用性能瓶颈;④预测、分析潜在的稳定性风险。
当前市场上具备运维数据分析能力的APM产品主要是面向企业应用的传统APM产品(如CA APM)和面向互联网应用的新型APM产品(如NewRelic、Dynatrace、Netuitive等)。在新发布的产品中,CA APM重点强调主动性能管理能力,通过预测应用未来的负载变化趋势,指导用户优化应用资源配置;NewRelic、Dynatrace强调分析的实时性,提供围绕在线用户、应用事务、用户体验相关的数据统计分析功能,以易于理解的方式将当前围绕应用健康状态的分析结果展示给用户;Netuitive则重点打造面向未来的预测分析能力,利用机器学习回归算法,通过分析历史监控指标数据来给出未来一段时间的指标曲线波动情况。除此以外,Netuitive还能够通过独特的行为学习技术,学习指定时间范围内的监控指标波动状态,发现指标之间的关联关系,预测未来可能发生的异常,并提前生成主动告警。
随着信息技术的快速发展,企业运营对数字信息系统的依赖加大,IT运维的重要性和成本快速增加。同时,新一代信息技术和创新业务流程也在推动系统复杂化,人工运维已经难堪重负,智能运维被寄予厚望。近几年来,无论是学术界还是产业界,对智能运维领域技术和应用的关注度都在快速提升。ExtraHop在2016年面向大中型企业的调查报告中指出,60%的企业有计划整合竖井式的分布异构运维数据源,实现统一运维数据存储分析平台[1]。Gartner预测,到2022年,40%的企业将会部署智能运维平台,实现运维智能化。
2.3 演进过程
在IT运维初级阶段,企业就有动力通过以算法和自动化流程驱动的“智能运维”来代替人工。当时,信息系统主要以企业内部自用的企业资源管理、计算机服务设计等系统为主,系统服务范围小,运维成本和压力相对较小。企业没有足够的动力来做IT运维智能化的事情。智能运维发展加速的一个重要的催化剂是,如Google这样的互联网公司迫于运维压力,开始尝试利用统计学方法分析运维数据中的模式,预测未来趋势。从2010年开始,云计算和大数据技术的快速发展也推动了企业利用大数据与算法提升IT运维能力的需求,智能运维发展真正进入了快车道。时至今日,在智能运维的演进过程中,主要的里程碑有IT运维分析、事件关联分析、自动化运维、人工智能运维、开发运维一体化。
2.3.1 IT运维分析
IT运维分析(IT Operations Analytics,ITOA)指实现基于海量IT运营数据的演绎、归纳推理,并支撑IT运营数据采集、存储、展现的相关技术及服务。其利用数学算法或创新方法,从海量IT监控管理系统采集的原始数据中挖掘有用的信息。ITOA是通过分析海量、低价值密度的IT系统的可用性和性能数据,发现复杂的数据模式,从而辅助优化企业IT运营过程的系统,其需要具备的核心能力如下。
(1)风险根源定位分析:通过融合分析来自基础设施、应用、用户的监控数据,定位产生风险或对系统健康造成潜在威胁的根源所在。
(2)性能可用性预测分析:基于历史数据预测未来系统性能和可用性的变化趋势,以及关联分析对系统可能产生的影响。
(3)问题识别与派发:围绕当前问题,从历史记录中查找解决方案和适合解决问题的团队或人,提高处理问题的效率。
(4)影响范围推理分析:当发现多个风险可能对系统造成影响时,基于从数据中发现的模式推理找出可能影响更大、优先级更高的风险,指导相关人员及时、高效处理这些问题,降低损失。
(5)多源数据融合互补:对IT基础设施和应用采集的数据进行关联、融合,补全网络、应用、服务拓扑结构,完善探查管理类工具信息视图。
(6)动态风险告警阈值管理:自动发现监控指标的正常运行范围,在用户负载变化或系统配置变更后,能够自动从历史数据中发现规律,调整异常告警区间的限定阈值范围。
对于ITOA技术,Gartner在Data Growth Demands a Single, Architected IT Operations Analytics Platform报告[2]中总结了六种:①日志分析技术;②非结构化文本数据索引、查询和推理技术;③拓扑分析技术;④多维数据库查询分析技术;⑤复杂运维事件处理技术;⑥数据统计分析、模式发现与识别技术。具备这些技术的ITOA才能满足基础设施和应用层的监控需求,实现由多源异构探针采集的时间序列指标、日志、代码链路、网络包和用户数字轨迹数据的聚合、关联和分析。目前,市场上的ITOA产品提供商主要有Splunk、Elastic、Dynatrace和RealSight APM等。
2.3.2 事件关联分析
在主动风险预测和预防性维护技术未成熟之前,企业运维风险管理工作主要以工单、风险告警等事件驱动工作方式为主。在运维过程中,事件关联分析(Event Correlation and Analysis,ECA)[3]则主要用来关联多种监控系统事件,协同不同团队角色人员的工作。具体地说,ECA能够帮助IT运维人员消除重复上报工单事件或告警;根据不同人员角色和业务运维需要来过滤、查询相关事件;根据历史数据或预定义规则关联事件,找出告警事件的根源问题或查找事件间的相关性和影响关系。这种处理方式在一定程度上能减少人工过滤无效事件的工作量,并辅助查找对应事件最合适的处理角色,这也是通过算法实现指定类型风险处理的智能运维的一种简单、有效的方案。市场上主要的ECA产品提供商有Argent Software、Augur Systems、BMC Software和CA。
2.3.3 自动化运维
如果说智能运维技术发展的主线是为了解放运维人员,ITOA、ECA通过数据驱动辅助决策来解放IT运维人员的大脑,那么,自动化运维(Automated System Operations,ASO)[4]技术则主要是为了解放运维人员的手和脚。在日常运维中,当面临大量服务器、应用,需要有限的运维人员维护管理时,自动化运维工具和产品能够帮助运维人员设置自动化脚本,批量安装操作系统,部署中间件和应用,配置变更管理。Gartner将ASO定义为“不需要人工干预,直接操控物理设备就能控制计算机安装配置硬件和软件的过程”。
借助ASO工具,IT运维人员可以在控制台通过定义自动化脚本准备应用的运行环境,安装部署应用,准备集群节点,控制弹性分组。结合脚本语言编程,运维人员可以将更复杂的控制流程自动化。结合ITOA和ECA的风险告警,以及根源定位分析事件触发,可以实现特定场景下对特定风险的自愈控制。比较常用的ASO工具包括Chef、Puppet、Ansible和Saltstack。
2.3.4 人工智能运维
第一个提出AIOps概念的是著名的IT咨询公司Gartner[5],其给出的定义是算法运维(Algorithmic IT Operations),其中的AI并不是现在大家理解的人工智能。2017年4月,在印度孟买的新闻会上,Gartner将AIOps解释为“AIOps平台由可以完成数据采集、存储、分析和可视化的多层架构系统组成,具备与第三方应用通过不与厂商绑定的API接口对接数据的能力,能够和IT运维管理(ITOM)类工具进行数据交互和能力对接”。Gartner完全站在IT运维数据分析的角度给出了AIOps的基本能力边界,和人工智能没有一点儿关系。然而,由于人工智能技术是大热点,业界更愿意将AI理解为更时髦的人工智能算法,AIOps也就只能顺应潮流,被定义为人工智能运维。从目前机器学习、人工智能技术的应用现状和发展趋势来看,IT运维领域的目标数据以机器数据为主,机器行为相比于人的行为规律性较强,状态数据采集简单,质量相对可控。使用算法运维替代人工运维更容易落地,真正的人工智能运维已经不再遥不可及。
从需求和技术发展的趋势看,企业内多源数据融合和集中式运维与运营数据支撑是大势所趋,但由于采集方式和数据类型多样、数据存储分散、智能分析场景众多,实现难度较大,需要从核心场景出发,按需规划,分阶段递进实现。Gartner给出的AIOps平台的核心能力包括以下几项。
(1)能够从多种数据源采集数据,不与厂商绑定。
(2)支持对接、处理实时数据和批量历史数据。
(3)提供对融合数据的检索、统计。
(4)提供海量实时、历史数据的存储。
(5)支持使用机器学习算法来分析、处理数据。
(6)能够基于分析结果规划下一步的处理动作。
总结企业应用的运维场景,可知常见的人工智能运维场景如下。
(1)基本和高级统计分析:单变量和多变量分析的组合,包括对跨 IT 实体捕获的指标使用相关性、聚类、分类和外推分析,以及从监控数据源中对数据进行整理。
(2)自动模式发现和预测:使用上述一种或多种类型的历史或流数据,得出数学或结构模式,描述可以从数据集本身推断但不会立即存在于数据集本身的新相关性;然后,这些模式可用于及时预测具有不同概率的事件。
(3)应用异常检测:使用前一个组件发现的模式,首先确定构成正常系统的行为,然后识别偏离该正常系统的行为。
(4)根本原因确定:向下修剪由自动模式发现和预测组件建立的相关网络,以隔离那些代表真正因果关系的依赖关系链接,从而提供有效干预的方法。
(5)规定性建议:对问题进行整理,将它们分类为已知类别;然后,挖掘以前解决方案的记录,分析这些解决方案是否适用,并优先提供这些解决方案,以便尽早使用补救措施;最终,使用闭环方法,并在使用后对其有效性进行表决。
(6)拓扑:对于AIOps检测到的具有相关性和可操作性的模式,必须围绕引入的数据放置上下文,该上下文就是拓扑;如果没有拓扑的上下文和事实上的约束,检测到的模式虽然有效,但可能毫无帮助且会分散注意力;拓扑中的数据派生模式将减少模式的数量,建立相关性并说明隐藏的依赖关系;使用拓扑作为因果关系确定的一部分可以大大提高其准确性和有效性;使用图形和瓶颈分析捕获事件发生的位置及其上下游的依赖关系,可以提供关于将补救工作重点集中到何处的见解。
一些企业,尤其是拥有庞大数据中心和复杂应用的互联网公司,已经将此技术应用于特定场景,比如用户异常行为检测、云端应用弹性控制、容量规划、入侵检测、数据中心PUE能效管理、硬盘损坏预测等。有些企业甚至开始尝试通过融合开发、运维、运营数据来打造一体化智能化平台,关联运营KPI和运维SLO,同时为企业各部门提供全景数据视图和智能决策支持。非IT运维部门,如业务规划部、销售部、产品部和数字营销部都有自己的应用系统和数据,也希望借助其他途径获取更丰富的数据以了解目标用户、市场和使用场景。数据量的激增也使得大数据采集、存储和智能分析成为必备技术。因此,为了满足企业内更广泛的需求,AIOps平台对接的数据源的种类在增加,能力边界也在扩大。例如,传统APM产品提供商Dynatrace已经在践行AIOps的基础上提出了软件智能(Software Intelligence)平台的概念,推出了数字业务分析(Digital Business Analytics)服务,能够为企业数字运营部门提供实时的用户数字体验监控、转化率变化分析、企业营收与应用性能关联分析和用户画像分类等服务。
2.3.5 开发运维一体化
现在企业更加依赖数字信息系统与最终用户交互,企业应用互联网化已经是大势所趋。对于互联网应用的开发与运维,开发运维一体化(DevOps)是回避不了的一个话题。根据Wikipedia[6]的解释,DevOps这个说法第一次出现在2009年比利时Ghent举办的一次由敏捷实践者、项目经理和咨询顾问参与的称为DevOpsDays的会议上。虽然截至目前,学术界和产业界对DevOps的概念还未达成共识,但从企业信息化系统应用开发、运维的实际需求出发,DevOps通常被理解为包含工具、过程和人的一系列最佳实践,融合了应用软件开发期管理(Dev)和运行期维护(Ops),旨在缩短应用全生命周期的开发过程,提升运行期应用的可靠性、可用性和性能。
业界将DevOps概念应用在软件系统运维过程中的实践最早可以追溯到Google提出SRE概念时。当互联网应用新功能上线周期越来越短、代码更新越来越频繁时,Google不得不想办法在满足频繁发布代码需求的同时,保障上线代码的可靠性与性能能够支撑大规模用户同时在线访问,以及提供高质量的最终用户体验。践行DevOps与实现软件自动化发布或制定产品研发工作计划无关,DevOps的初衷是通过提高软件开发与运维体系的衔接水平,将软件价值加速交付给企业的最终用户。要提供价值,企业必须在生产中运行应用程序以测试应用程序,并使用自动化流程管理工具来指导接下来交付的内容。
当企业践行DevOps,建设基于DevOps的应用开发、运维全生命周期管理体系时,应用智能运维系统只是其中支撑应用运行期管理环节的工具。为了支撑DevOps落地,应用智能运维系统不仅需要支撑应用运维人员实现运行期的状态监控、风险管理、用户数字体验保障,而且需要对接开发人员,实现在开发期定义应用业务监控关键KPI指标、分析运行期代码质量和支撑性能工程等过程,并且在新功能上线、代码更新时,支持A/B测试、灰度发布、蓝绿发布等应用场景。在具备面向运维提供代码级白盒监控的能力和风险主动感知的能力的同时,DevOps体系下的应用智能运维系统也需要无缝衔接开发,在代码有故障且运维人员无法处理时,需要快速找到责任人,向开发人员分享相关实时数据。如果应用上线后代码性能不达标,运行一段时间后,应用智能运维系统需要生成分析报告,指导后续性能优化和容量规划。
本章小结
智能运维是企业进一步提高运维效率、提升应用可用性和性能保障能力的关键。本章系统介绍了运维智能化过程中出现的IT运维分析、事件关联分析等一系列相关技术和产品,从背景起源、主要特点和应用场景方面概述了技术背景,相对完整地勾勒了智能运维的发展脉络,为后续介绍应用智能运维相关的技术和建设实践方法奠定了基础。
上一篇: 单细胞水平的红斑狼疮异质性分析
推荐阅读
-
智能运行与维护 - 智能运行与维护应用实践(试用版)
-
反传销网8月30日发布:视频区块链里的骗子,币里的韭菜,杜子建骂人了!金融大V周召说区块链!——“一小帮骗子玩一大帮小白,被割韭菜,小白还轮流被割,割的就是你!” 什么区块链,统统是骗子 作者:周召(知乎金融领域大V,毕业于上海财经大学,目前任职上海某股权投资基金合伙人) 有人问我,区块链现在这么火,到底是不是骗局? 我的回答是: 是骗局。而且我并不是说数字货币是骗局,而是说所有搞区块链的都是骗局。 -01- 区块链是一种鸡肋技术 人类社会任何技术的发明应用,本质都是为了提高社会的生产效率。而所谓区块链技术本质不过是几种早已成熟的技术的大杂烩,冗余且十分低效,除了提高了洗钱和诈骗的效率以外,对人类社会的进步毫无贡献。 真正意义上的区块链得包含三个要素:分布式系统(包括记账和存储),无法篡改的数据结构,以及共识算法,三者互为基础和因果,就像三体世界一样。看上去挺让人不明觉厉的,而经过几年的瞎折腾,稍微懂点区块链的碰了几次壁后都已经渐渐明白区块链其实并没有什么卵用,区块链技术已经名存实亡,沦为了营销工具和传销组织的画皮。 因为符合上述定义的、以比特币为代表的原教旨区块链技术,是反效率的,从经济学角度来说,不但不是一种帕累托改进,甚至还可以说是一种帕累托倒退。 原教旨区块链技术的效率十分低下,因为要遍历所有节点,只能做非常轻量级的数据应用,一旦涉及到大量的数据传输与更新,区块链就瞎了。 一方面整条链交易速度会极慢,另一方面数据库容量极速膨胀,考虑到人手一份的存储机制,区块链其实是对存储资源和能源的一种极大的浪费。 这里还没有加上为了取得所谓的共识和挖矿消耗的巨大的能源,如果说区块链技术是屎,那么这波区块链投机浪潮可谓人类历史上最大规模的搅屎运动。 区块链也验证不了任何东西。 所谓的智能合约,即不智能,也非合约。我看有人还说,如果有了智能合约,就可以跟老板签一份放区块链上,如果明年销售业绩提升30%,就加薪10%,由于区块链不能篡改,不能抵赖,所以老板必须得执行,说得有板有眼,不懂行的愣一看,好像还真是那么回事。 但仔细一想,问题就来了。首先,在区块链上如何证明你真的达到了30%业绩提升?即便真的达到老板耍赖如何执行? 也就是说,如果区块链真这么厉害,要法院和仲裁干什么。 人类社会真正的符合成本效益原则的是代理制度。之前有人说要用区块链改造注册会计师行业,我不知道他准备怎么设计,我猜想他思路大概是这样的,首先肯定搞去中心化,让所有会计师到链上来,然后一个新人要成为注册会计师就要所有会计师同意并记录在链上。 那我就请问了,我每天上班累死累活,为什么还要花时间去验证一个跟我无关的的人的专业能力?最优做法当然是组织一个委员会,让专门的人来负责,这不就是现在注册会师协会干的事儿吗?区块链的逻辑相当于什么事情都要拿出来公投,这个绝对是扯淡的。 当然这么说都有点抬举区块链了,区块链技术本身根本没有判断是非能力,如果这么高级的人工智能,靠一个无脑分布式记账就能实现的话,我们早就进入共产主义社会了。 虽然EOS等数字货币采用了超级节点,通过再中心化的方式提高效率,有点行业协会的意思,是对区块链原教旨主义的一种修正,但是依然无法突破区块链技术最本质的局限性。有人说,私有链和联盟链是区块链技术的未来,也是扯淡,因为区块链技术没有未来。如果有,说明他是包装成区块链的伪区块链技术。 区块链所涉及的所有底层技术,不管是分布式数据库技术,加密技术,还是点对点传输技术等,基本都是早已存在没什么秘密可言的技术。 比特币系统最重要的特性是封闭性和自洽性,他验证不了任何系统自身以外产生的信息的真实性。 所谓系统自身产生的信息,就是数据库数据的变动信息,有价值的基本上有且只有交易信息。所以说比特币最初不过是中本聪一种炫技的产物,来证明自己对几种技术的掌握,你看我多牛逼,设计出了一个像三体一样的系统。因此,数字货币很有可能是区块链从始至终唯一的杀手应用。 比特币和区块链概念从诞生到今天已经快10年了,很多人说区块链技术在爆发的前夜,但这个前夜好像是不是有点过长了啊朋友,跟三体里的长夜有一拼啊。都说区块链技术像是90年代初的互联网,可是90年代初的互联网在十年发展后,已经出现了一大批伟大的公司,阿里巴巴在99年都成立了,区块链怎么除了币还是币呢? 正规的数字货币未来发展的形式无外乎几种,要么就是论坛币形式,或者类似股票的权益凭证等。问题是论坛币和股票之前,本来也都电子化了,区块链来了到底改变了什么呢? 所有想把TOKEN和应用场景结合起来的人最后都很痛苦,最后他们会发现区块链技术就是脱裤子放屁,自己辛苦搞半天,干嘛不自己作为中心关心门来收钱?最后这些人都产生了价值的虚无感,最终精神崩溃,只能发币疯狂收割韭菜,一边嘴里还说着我是个好人之类的奇怪的话。 因此,之前币圈链圈还泾渭分明,互相瞧不起,但这两年链圈逐渐坐不住了,想着是不是趁着泡沫没彻底破灭之前赶快收割一波,不然可能什么都捞不着了。 前段时间和一个名校毕业的链圈朋友瞎聊天,他说他们“致力于用区块链技术解决数字版权保护问题”,我就问他一个问题,你们如何保证你链的版权所有权声明是真实的,万一盗版者抢先一步把数据放在链上怎么办。他说他们的解决方案是连入国家数字版权保护中心的数据库进行验证…… 所以说区块链技术就是个鸡肋,研究到最后都会落入效率与真实性的黑洞,很多人一头扎进链圈后才发现,真正意义上的区块链技术,其实什么都干不了。 -02- 不是蠢就是坏的区块链媒体 空气币和区块链的造富神话,让区块链自媒体也开始迎风乱扭。一群群根本不知道区块链为何物的妖魔鬼怪纷纷进驻区块链自媒体战场,开始大放厥词胡编乱造。 任何东西,但凡只要和区块,链,分,分布式,记账,加密,验证,可追溯等等这些个关键词沾到哪怕一点点,这些所谓的区块链媒体人就会像狗闻到了屎了一样疯狂地把区块链概念往上套。 这让我想起曾经一度也是热闹非凡的物联网,我曾经去看过江苏一家号称要改变世界的“物联网”企业,过去一看是生产路由器的,我黑人问号脸,对方解释说没有路由器万物怎么互联,我觉得他说得好有道理,竟无言以对。 好,下面让我们进入奇葩共赏析时间,来看看区城链媒体经常有哪些危言耸听的奇谈怪论 区块链(分布式记账)的典型应用是*?? 正如前面所说,真正意义上的区块链分布式记账,不光包括“记”这个动作,还包括分布式存储和共识机制等。而*诞生远远早于区块链这个词的出现,勉强算是“分布式编辑”吧,就被很多区块链媒体拿来强行充当区块链技术应用的典范。 其实事实恰恰相反,*恰恰是去中心化失败的典范,现在如果没有精英和专业人士的编辑和维护,*早就没法看了。 区块链会促进社会分工?? 罗振宇好像就说过类似的话,虽然罗振宇说过很多没有逻辑的话,但这句话绝对是最没逻辑思维的。很多区块链自媒体也常常用这句话来忽悠老百姓,说分工代表效率提高社会进步,而区块链“无疑”会促进分工,他们的理由仅仅是分工和分布式记账都共用一个“分”字,就强行把他们扯到一起。 实际情况恰恰相反,区块链是逆分工的,区块链精神是号召所有人积极地参与到他不擅长也不想掺合的事情里面去。 区块链不能像上帝一样许诺他的子民死后上天国,只能给他们许诺你们是六度人脉中的第一级,我可以赚后面五级人的钱,你处于金字塔的顶端。
-
小红书消息中间件的运行维护实践与管理之路
-
企业运维弹性计算原理与实践 - ECS 高级概念 - 运维 - 第 3 章(上):ECS 高级概念 - 运行和维护 (1)
-
澎湃新闻对话腾讯丁珂:从 "治已病 "到 "治未病",企业需快速构建 "安全免疫力"--丁珂指出,对企业而言,安全不是成本而是生命线 丁珂指出,对企业而言,安全不是成本而是生命线,也是商业 "硬币 "的另一面。在数字智能化的新阶段,发展驱动安全建设已成为普遍共识,企业需要转变安全思维,从被动建设到主动防御,构建一套新的安全范式和框架,以更加积极、主动的安全观来提升数字安全免疫力,以 "治未病 "的理念取代 "治已病",前置安全,快速构建 "安全免疫力"。对 "已病",前置预判,及时应对处置安全风险,才能维护品牌价值,保障健康发展。 与此同时,安全建设还普遍存在 "不知道往哪投、怎么投 "的痛点。对此,腾讯安全提出,企业可以按照数字安全免疫模型的框架进行安全全局部署,重点在业务安全、数据安全、安全运维管理、边界安全、终端安全、应用开发安全等薄弱环节的关键领域注入 "免疫增强针"。 今年进入公众视野的AIGC还在产业化、产品化的过程中,但大量攻击者已经利用它生成攻击脚本、钓鱼邮件,甚至伪造身份进行诈骗。"人工智能本身是否安全,会不会让网络更不安全? 腾讯安全研究认为,AIGC的风险主要集中在 "无法解释 "和 "无法追踪 "的特点上,但这在技术上是能够找到应对方法的。丁珂谈到,AIGC作为生产力的巨大提升,确实会带来更复杂的攻防态势和更大的防御难度。但任何新技术都要经历这样的周期。而法律法规也会随着技术的演进而不断更新,使新技术的发展更加规范和健全。 丁珂认为,随着我国网络安全法律法规体系的不断完善,合规性将给企业推进网络安全带来很大的推动力,并很直观地展现在需求端。未来,伴随着数据要素市场的建立或企业对数据价值的挖掘,也将带动数据安全市场的快速增长。 对于腾讯安全的商业逻辑和运营,丁珂表示,不谋求建立竞争壁垒,而是期望与生态共同发展,腾讯安全希望通过能力开放,实现安全与业务相伴的生态模式。 谈到未来,丁磊表示,安全领域已经进入加速发展期,在蓝海中会持续关注很多新的业务领域,希望孵化出新的商业模式,腾讯安全团队也会持续关注并抓住机会做好产品。 以下为采访实录(在不改变原意的基础上略有删减): 冲浪新闻:当前,以人工智能、大数据等新技术为驱动的第四次工业革命正向纵深推进,给人类生产生活带来深刻变革。而互联网作为新技术的载体,面临的安全挑战不仅数量越来越多,形式也越来越复杂。从互联网安全从业者的角度,腾讯观察到近年来国内外网络安全形势发生了哪些变化?这些变化呈现出怎样的趋势?
-
运行和维护大规模 ES 集群的思考与实践
-
windows下进程间通信的(13种方法)-摘 要 本文讨论了进程间通信与应用程序间通信的含义及相应的实现技术,并对这些技术的原理、特性等进行了深入的分析和比较。 ---- 关键词 信号 管道 消息队列 共享存储段 信号灯 远程过程调用 Socket套接字 MQSeries 1 引言 ---- 进程间通信的主要目的是实现同一计算机系统内部的相互协作的进程之间的数据共享与信息交换,由于这些进程处于同一软件和硬件环境下,利用操作系统提供的的编程接口,用户可以方便地在程序中实现这种通信;应用程序间通信的主要目的是实现不同计算机系统中的相互协作的应用程序之间的数据共享与信息交换,由于应用程序分别运行在不同计算机系统中,它们之间要通过网络之间的协议才能实现数据共享与信息交换。进程间通信和应用程序间通信及相应的实现技术有许多相同之处,也各有自己的特色。即使是同一类型的通信也有多种的实现方法,以适应不同情况的需要。 ---- 为了充分认识和掌握这两种通信及相应的实现技术,本文将就以下几个方面对这两种通信进行深入的讨论:问题的由来、解决问题的策略和方法、每种方法的工作原理和实现、每种实现方法的特点和适用的范围等。 2 进程间的通信及其实现技术 ---- 用户提交给计算机的任务最终都是通过一个个的进程来完成的。在一组并发进程中的任何两个进程之间,如果都不存在公共变量,则称该组进程为不相交的。在不相交的进程组中,每个进程都独立于其它进程,它的运行环境与顺序程序一样,而且它的运行环境也不为别的进程所改变。运行的结果是确定的,不会发生与时间相关的错误。 ---- 但是,在实际中,并发进程的各个进程之间并不是完全互相独立的,它们之间往往存在着相互制约的关系。进程之间的相互制约关系表现为两种方式: ---- (1) 间接相互制约:共享CPU ---- (2) 直接相互制约:竞争和协作 ---- 竞争——进程对共享资源的竞争。为保证进程互斥地访问共享资源,各进程必须互斥地进入各自的临界段。 ---- 协作——进程之间交换数据。为完成一个共同任务而同时运行的一组进程称为同组进程,它们之间必须交换数据,以达到协作完成任务的目的,交换数据可以通知对方可以做某事或者委托对方做某事。 ---- 共享CPU问题由操作系统的进程调度来实现,进程间的竞争和协作由进程间的通信来完成。进程间的通信一般由操作系统提供编程接口,由程序员在程序中实现。UNIX在这个方面可以说最具特色,它提供了一整套进程间的数据共享与信息交换的处理方法——进程通信机制(IPC)。因此,我们就以UNIX为例来分析进程间通信的各种实现技术。 ---- 在UNIX中,文件(File)、信号(Signal)、无名管道(Unnamed Pipes)、有名管道(FIFOs)是传统IPC功能;新的IPC功能包括消息队列(Message queues)、共享存储段(Shared memory segment)和信号灯(Semapores)。 ---- (1) 信号 ---- 信号机制是UNIX为进程中断处理而设置的。它只是一组预定义的值,因此不能用于信息交换,仅用于进程中断控制。例如在发生浮点错、非法内存访问、执行无效指令、某些按键(如ctrl-c、del等)等都会产生一个信号,操作系统就会调用有关的系统调用或用户定义的处理过程来处理。 ---- 信号处理的系统调用是signal,调用形式是: ---- signal(signalno,action) ---- 其中,signalno是规定信号编号的值,action指明当特定的信号发生时所执行的动作。 ---- (2) 无名管道和有名管道 ---- 无名管道实际上是内存中的一个临时存储区,它由系统安全控制,并且独立于创建它的进程的内存区。管道对数据采用先进先出方式管理,并严格按顺序操作,例如不能对管道进行搜索,管道中的信息只能读一次。 ---- 无名管道只能用于两个相互协作的进程之间的通信,并且访问无名管道的进程必须有共同的祖先。 ---- 系统提供了许多标准管道库函数,如: pipe——打开一个可以读写的管道; close——关闭相应的管道; read——从管道中读取字符; write——向管道中写入字符; ---- 有名管道的操作和无名管道类似,不同的地方在于使用有名管道的进程不需要具有共同的祖先,其它进程,只要知道该管道的名字,就可以访问它。管道非常适合进程之间快速交换信息。 ---- (3) 消息队列(MQ) ---- 消息队列是内存中独立于生成它的进程的一段存储区,一旦创建消息队列,任何进程,只要具有正确的的访问权限,都可以访问消息队列,消息队列非常适合于在进程间交换短信息。 ---- 消息队列的每条消息由类型编号来分类,这样接收进程可以选择读取特定的消息类型——这一点与管道不同。消息队列在创建后将一直存在,直到使用msgctl系统调用或iqcrm -q命令删除它为止。 ---- 系统提供了许多有关创建、使用和管理消息队列的系统调用,如: ---- int msgget(key,flag)——创建一个具有flag权限的MQ及其相应的结构,并返回一个唯一的正整数msqid(MQ的标识符); ---- int msgsnd(msqid,msgp,msgsz,msgtyp,flag)——向队列中发送信息; ---- int msgrcv(msqid,cmd,buf)——从队列中接收信息; ---- int msgctl(msqid,cmd,buf)——对MQ的控制操作; ---- (4) 共享存储段(SM) ---- 共享存储段是主存的一部分,它由一个或多个独立的进程共享。各进程的数据段与共享存储段相关联,对每个进程来说,共享存储段有不同的虚拟地址。系统提供的有关SM的系统调用有: ---- int shmget(key,size,flag)——创建大小为size的SM段,其相应的数据结构名为key,并返回共享内存区的标识符shmid; ---- char shmat(shmid,address,flag)——将当前进程数据段的地址赋给shmget所返回的名为shmid的SM段; ---- int shmdr(address)——从进程地址空间删除SM段; ---- int shmctl (shmid,cmd,buf)——对SM的控制操作; ---- SM的大小只受主存限制,SM段的访问及进程间的信息交换可以通过同步读写来完成。同步通常由信号灯来实现。SM非常适合进程之间大量数据的共享。 ---- (5) 信号灯 ---- 在UNIX中,信号灯是一组进程共享的数据结构,当几个进程竞争同一资源时(文件、共享内存或消息队列等),它们的操作便由信号灯来同步,以防止互相干扰。 ---- 信号灯保证了某一时刻只有一个进程访问某一临界资源,所有请求该资源的其它进程都将被挂起,一旦该资源得到释放,系统才允许其它进程访问该资源。信号灯通常配对使用,以便实现资源的加锁和解锁。 ---- 进程间通信的实现技术的特点是:操作系统提供实现机制和编程接口,由用户在程序中实现,保证进程间可以进行快速的信息交换和大量数据的共享。但是,上述方式主要适合在同一台计算机系统内部的进程之间的通信。 3 应用程序间的通信及其实现技术 ---- 同进程之间的相互制约一样,不同的应用程序之间也存在竞争和协作的关系。UNIX操作系统也提供一些可用于应用程序之间实现数据共享与信息交换的编程接口,程序员可以通过自己编程来实现。如远程过程调用和基于TCP/IP协议的套接字(Socket)编程。但是,相对普通程序员来说,它们涉及的技术比较深,编程也比较复杂,实现起来困难较大。 ---- 于是,一种新的技术应运而生——通过将有关通信的细节完全掩盖在某个独立软件内部,即底层的通讯工作和相应的维护管理工作由该软件内部来实现,用户只需要将通信任务提交给该软件去完成,而不必理会它的具体工作过程——这就是所谓的中间件技术。 ---- 我们在这里分别讨论这三种常用的应用程序间通信的实现技术——远程过程调用、会话编程技术和MQSeries消息队列技术。其中远程过程调用和会话编程属于比较低级的方式,程序员参与的程度较深,而MQSeries消息队列则属于比较高级的方式,即中间件方式,程序员参与的程度较浅。 ---- 4.1 远程过程调用(RPC)