比特币和区块链已经不是什么新闻话题了,然而还是有不少朋友在各种场合问笔者什么是比特币,什么是区块链,它们之间有什么关系?笔者用一些形象的比喻来解说一下吧。

区块链.jpg

区块链是一种技术,是一种不管比特币存在与否他都存在的一种逻辑。只要存在信任危机的场景,都可以尝试利用区块链技术来看看是否有帮助解决困境的可能性。例如:合约、记账等场景。

比特币,是建立的区块链技术上的虚拟货币,去掉比特二字,也就是一种虚拟货币,如同游戏币一样,基于某种规则,而这种规则是特定场景的金融或虚拟金融规则(可以用来购买虚拟物品、支付服务等)。通过兑换成法定货币可实现价值,在某些国家也可以交易。(这和游戏币非常相像,可以通过某种特定手段兑换成法币,也可以在虚拟的国度进行交易。)

在这里简单总结:区块链是技术、比特币是虚拟金融工具。两者的关系只是比特币刚好使用了区块链技术而已。

那么比特币和区块链的这种关系如何理解呢?我们来做一个简单的比喻,为勘测发射卫星、为克敌制胜发射导弹都会用到相同,它们都使用了可制导的火箭技术,区块链就如同这火箭一样是一种基础技术,它是一种基础计算逻辑的实现,包括加密和分布式存储。

作为一种技术,区块链有很多中衍生的实现方式,如同火箭的动力(液体的、固体的)、制导技术(激光制导、电视制导、红外制导等)各有差异一样,他们可以选择自己的加密方案,可以规定自己的分布存储规则。

作为虚拟金融工具,可以有很多种币,其价值并不取决于其是否使用了区块链技术,而是人们对这种币的信心。如同:卫星发射,它可以用航天飞机,不一定只有火箭才能将其送上天。

让凯撒的归凯撒。

最后,留一个思考题:由“中本聪”唯一制定了规则的比特币真的做到了去中心化吗?

比特币和区块链已经不是什么新闻话题了,然而还是有不少朋友在各种场合问笔者什么是比特币,什么是区块链,它们之间有什么关系?笔者用一些形象的比喻来解说一下吧。

区块链.jpg

区块链是一种技术,是一种不管比特币存在与否他都存在的一种逻辑。只要存在信任危机的场景,都可以尝试利用区块链技术来看看是否有帮助解决困境的可能性。例如:合约、记账等场景。

比特币,是建立的区块链技术上的虚拟货币,去掉比特二字,也就是一种虚拟货币,如同游戏币一样,基于某种规则,而这种规则是特定场景的金融或虚拟金融规则(可以用来购买虚拟物品、支付服务等)。通过兑换成法定货币可实现价值,在某些国家也可以交易。(这和游戏币非常相像,可以通过某种特定手段兑换成法币,也可以在虚拟的国度进行交易。)

在这里简单总结:区块链是技术、比特币是虚拟金融工具。两者的关系只是比特币刚好使用了区块链技术而已。

那么比特币和区块链的这种关系如何理解呢?我们来做一个简单的比喻,为勘测发射卫星、为克敌制胜发射导弹都会用到相同,它们都使用了可制导的火箭技术,区块链就如同这火箭一样是一种基础技术,它是一种基础计算逻辑的实现,包括加密和分布式存储。

作为一种技术,区块链有很多中衍生的实现方式,如同火箭的动力(液体的、固体的)、制导技术(激光制导、电视制导、红外制导等)各有差异一样,他们可以选择自己的加密方案,可以规定自己的分布存储规则。

作为虚拟金融工具,可以有很多种币,其价值并不取决于其是否使用了区块链技术,而是人们对这种币的信心。如同:卫星发射,它可以用航天飞机,不一定只有火箭才能将其送上天。

让凯撒的归凯撒。

最后,留一个思考题:由“中本聪”唯一制定了规则的比特币真的做到了去中心化吗?

即使不是IT人,很多都经历过这样的情形:使用X家的操作系统,B家的应用程序,在出现问题的时候两家互相推诿的现象。那么云计算的背后,有多少服务商参与呢?出现问题该怎么办?

性能分析是IT运维的日常工作,基于排除障碍或优化的目的,IT人都会对系统进行性能分析。然而在云计算形态下,性能分析及故障处理正在变得复杂。

请看这样一个案例(本文基于真实案例对故事情节进行了适当处理):某日,一IT人M受朋友之托(S公司),检查S公司使用的云计算(A公司提供)服务性能问题,因为其作为客户和云计算服务商(A公司)出现了争议,A公司认为S公司所在网络有严重性能问题,因此不能良好的访问其提供的服务,而M则认为A公司的云部署架构不良导致了性能问题。S公司的负责人和IT人M非常熟识,深知其功力,因此请M指导S公司的IT团队进行检查判断,以期获得良好的使用体验。M受托后,对网络带宽、路径、时延、路径等技术问题(带参数ping、tracert)进行了初步检查,发现A公司提供的服务,会重新指向B公司,以获得B公司提供的waf服务。最终的检查结果不再细述,我们依然从中可以得到一个基本现象,参与云计算的服务商体系会越来越庞大。

云计算随着功能、性能、安全,以及行业划分,等等多种因素的影响,使得最终用户在获取一项基本服务的背后,有若干服务商隐形的参与的服务的提供(例如:抗DDoS、防火墙、SaaS、IaaS等),而当使用者面临一个故障时,他/她很难判断出这个故障是服务商的哪一个环节出了问题,何况使用者到云计算服务商之间还有网络运营商的存在。而这种现象不仅仅是降低了使用者的体验,对于云计算提供商而言也是一个严峻的挑战。

云计算厂商面临的挑战是应对复杂的外包环境,甚至是层层外包,如何协调管理和技术问题。

作为使用者,需要知情权,从而为使用何种云计算,以及选择服务商等决策问题做出判断。

即使不是IT人,很多都经历过这样的情形:使用X家的操作系统,B家的应用程序,在出现问题的时候两家互相推诿的现象。那么云计算的背后,有多少服务商参与呢?出现问题该怎么办?

性能分析是IT运维的日常工作,基于排除障碍或优化的目的,IT人都会对系统进行性能分析。然而在云计算形态下,性能分析及故障处理正在变得复杂。

请看这样一个案例(本文基于真实案例对故事情节进行了适当处理):某日,一IT人M受朋友之托(S公司),检查S公司使用的云计算(A公司提供)服务性能问题,因为其作为客户和云计算服务商(A公司)出现了争议,A公司认为S公司所在网络有严重性能问题,因此不能良好的访问其提供的服务,而M则认为A公司的云部署架构不良导致了性能问题。S公司的负责人和IT人M非常熟识,深知其功力,因此请M指导S公司的IT团队进行检查判断,以期获得良好的使用体验。M受托后,对网络带宽、路径、时延、路径等技术问题(带参数ping、tracert)进行了初步检查,发现A公司提供的服务,会重新指向B公司,以获得B公司提供的waf服务。最终的检查结果不再细述,我们依然从中可以得到一个基本现象,参与云计算的服务商体系会越来越庞大。

云计算随着功能、性能、安全,以及行业划分,等等多种因素的影响,使得最终用户在获取一项基本服务的背后,有若干服务商隐形的参与的服务的提供(例如:抗DDoS、防火墙、SaaS、IaaS等),而当使用者面临一个故障时,他/她很难判断出这个故障是服务商的哪一个环节出了问题,何况使用者到云计算服务商之间还有网络运营商的存在。而这种现象不仅仅是降低了使用者的体验,对于云计算提供商而言也是一个严峻的挑战。

云计算厂商面临的挑战是应对复杂的外包环境,甚至是层层外包,如何协调管理和技术问题。

作为使用者,需要知情权,从而为使用何种云计算,以及选择服务商等决策问题做出判断。

信息安全技术中有一种识别叫击键习惯。

击键记录.png

那么大家在互联网的各种操作如何进行分析?

点击物品的类别

点击物品类别间的关系

点击物品顺序

点击重复次数

总计点击次数

点击频率

停留时间

停留在他人点击次数位置上

抽象点说,点击+时间间隔;统计分析、时序分析……

具体点说,能够知道你看了XX,你又看了XX,你晒了XX,你取消了XX……

信息安全技术中有一种识别叫击键习惯。

击键记录.png

那么大家在互联网的各种操作如何进行分析?

点击物品的类别

点击物品类别间的关系

点击物品顺序

点击重复次数

总计点击次数

点击频率

停留时间

停留在他人点击次数位置上

抽象点说,点击+时间间隔;统计分析、时序分析……

具体点说,能够知道你看了XX,你又看了XX,你晒了XX,你取消了XX……

笔者在前文提出“RPA的效能表现取决于养成师对机器人的训练、调校和管理,因此对于RPA而言成功的关键是养成师团队的构建。企业可以根据情况选择自建、外包、咨询,以及混成模式的养成师团队。养成师的团队需要业务专家和系统工程师共同组成,当然,一个高瞻远瞩的团队领袖是团队成功的保障。也就算是说,机器人的最终产出仍然取决于人。”在此,笔者将就RPA实施的成功因素进行展开讨论。

所有结论基于笔者的工作经验和对RPA的实际测试。

RPA.png

首先,我们需要注意到RPA中,P(rocess)是指业务流程,实施RPA的前提条件是必须深度解读业务流程并建模,而这一点对于很多企业都是有挑战的。这要求RPA团队中必须要有资深业务分析师,他能够将业务流程归纳为流程模型。虽然现在从业人员对于计算机应用都能熟练使用,但根据笔者的经验,我们多数情况下不能寄希望于让业务人员来实现RPA,RPA仍需专业系统人员来完成。例如:一个没有IT知识的财务人员是无法实现RPA的,同样如果让一个从无财务经验的程序员完成财务RPA,可以想想出这一定是个灾难。

第二,RPA中的A(utomation)是指自动化。普遍意义的RPA不是人工智能(当前也无法做到人工智能级的RPA),其使用场景是将业务流程的操作实现自动化,其分支条件和相应执行都是根据预设场景而制定的,因此在实施RPA的过程中,需要适度考虑ROI,RPA更好的适用于大量重复工作的自动化。对于具有单一、不可预测变化的业务流程,RPA的投入可能带不来期望的回报。你可以想想一个月只执行一次,并且每个月可能都会出现变化的业务流程,如果用RPA解决会是怎样的结果。而每天执行数百、上千次,业务流程长期不变,RPA一定会比雇佣更多的员工更有效。而自动化来自于程序员的贡献。

第三,RPA实施需要编程能力,对于不同的商业RPA工具,其编程技能要求不同。无论是java、.Net,疑惑是其他,这都需要系统人员熟练掌握其工具。很多项目的失败即缘由管理人员出于不同原因未使用合格的程序员而导致。项目经理不要寄希望于程序员是多能的,同时具备多种能力的程序员没有想象中的那么常见。

第四,大型RPA应用和终端部署的规模不同,因此,很多RPA需要后台管理服务,而这种规模的部署加大了系统复杂度,尤其是在运维阶段。RPA的运维和其他应用程序的运维的区别在于它需要一定的编程知识,因此成功的RPA项目需要考虑后期的运维支持能力。

第五:关于涉及物理操作的RPA,笔者的建议对于现实条件抱有客观的态度。例如:自动进纸扫描仪会随着使用年限,卡纸的概率提高;OCR在某些场景下的识别率并不如人意,对结果的校验所费的人力可能会远远超过节省的人力。

从以上几个关键因素来看,RPA项目的成功最终取决于团队。

笔者在前文提出“RPA的效能表现取决于养成师对机器人的训练、调校和管理,因此对于RPA而言成功的关键是养成师团队的构建。企业可以根据情况选择自建、外包、咨询,以及混成模式的养成师团队。养成师的团队需要业务专家和系统工程师共同组成,当然,一个高瞻远瞩的团队领袖是团队成功的保障。也就算是说,机器人的最终产出仍然取决于人。”在此,笔者将就RPA实施的成功因素进行展开讨论。

所有结论基于笔者的工作经验和对RPA的实际测试。

RPA.png

首先,我们需要注意到RPA中,P(rocess)是指业务流程,实施RPA的前提条件是必须深度解读业务流程并建模,而这一点对于很多企业都是有挑战的。这要求RPA团队中必须要有资深业务分析师,他能够将业务流程归纳为流程模型。虽然现在从业人员对于计算机应用都能熟练使用,但根据笔者的经验,我们多数情况下不能寄希望于让业务人员来实现RPA,RPA仍需专业系统人员来完成。例如:一个没有IT知识的财务人员是无法实现RPA的,同样如果让一个从无财务经验的程序员完成财务RPA,可以想想出这一定是个灾难。

第二,RPA中的A(utomation)是指自动化。普遍意义的RPA不是人工智能(当前也无法做到人工智能级的RPA),其使用场景是将业务流程的操作实现自动化,其分支条件和相应执行都是根据预设场景而制定的,因此在实施RPA的过程中,需要适度考虑ROI,RPA更好的适用于大量重复工作的自动化。对于具有单一、不可预测变化的业务流程,RPA的投入可能带不来期望的回报。你可以想想一个月只执行一次,并且每个月可能都会出现变化的业务流程,如果用RPA解决会是怎样的结果。而每天执行数百、上千次,业务流程长期不变,RPA一定会比雇佣更多的员工更有效。而自动化来自于程序员的贡献。

第三,RPA实施需要编程能力,对于不同的商业RPA工具,其编程技能要求不同。无论是java、.Net,疑惑是其他,这都需要系统人员熟练掌握其工具。很多项目的失败即缘由管理人员出于不同原因未使用合格的程序员而导致。项目经理不要寄希望于程序员是多能的,同时具备多种能力的程序员没有想象中的那么常见。

第四,大型RPA应用和终端部署的规模不同,因此,很多RPA需要后台管理服务,而这种规模的部署加大了系统复杂度,尤其是在运维阶段。RPA的运维和其他应用程序的运维的区别在于它需要一定的编程知识,因此成功的RPA项目需要考虑后期的运维支持能力。

第五:关于涉及物理操作的RPA,笔者的建议对于现实条件抱有客观的态度。例如:自动进纸扫描仪会随着使用年限,卡纸的概率提高;OCR在某些场景下的识别率并不如人意,对结果的校验所费的人力可能会远远超过节省的人力。

从以上几个关键因素来看,RPA项目的成功最终取决于团队。

作为IT安全人员,相信每一位都知道“知所必须”原则,结合“最小权限”的就是两个“最小化”原则,是很多IT安全人员在入门课上就学到的。怎样才是最小,相信也是IT安全人员一直孜孜追求的,很多人困惑于“如何将信息尽可能少的传递、权限尽可能小的授予,并能保证该岗位执行其正常工作。

首先,我们来看一个广为流传案例:“沃尔玛的任何一位员工,不论他/她的级别如何,如果获知其他地方卖的某样东西比沃尔玛便宜,他/她就有权把沃尔玛的同类商品进行降价”。这是一个授权,而这个权利对于很多企业来讲,非常“不小“。而沃尔玛的授权体系远不止如此,他们采取“店中店”的模式授权部门经理管理自己的业务,并认为信息共享的前提下,授权才会起到作用,因此沃尔玛的员工对采购价格、运输成本等数据(这些数据在很多企业被视为机密数据)都了如指掌的,难道沃尔玛不怕泄密事件的发生吗?

在此,笔者结合工作经验,来讲一些你所不知道的秘密。

应知的信息和应有的权限,是业务战略的结果。信息是为业务目标服务的,这一条是信息安全的基本定律,而很多信息安全人员在工作中却不知道或者忘记了这一基本定律,从信息安全去推导业务。从信息安全推导战略是一个错误的方向,信息安全需要结合行业特色、企业业务战略来制定,而不是采用僵化的所谓信息安全理论限制企业业务的发展。作为企业的管理层,更需要知道信息安全与业务战略之间的关系,并采取相应的风险管理策略。

信息的时效是信息安全的策略和手段需要重点关注的属性。例如:企业财务报告,尤其是上市公司的财务报告,被特定人群获知的时间点会影响其股票价格等因素,因此在某时点前是秘密,而在公开后必须保持持续可见性。

信息安全的属性是弹性的,与企业管理特色相关。例如:奖金信息,在某些企业是用来作为激励手段,只有公开了奖金信息,最少也应该分等级公开才能起到激励作用。随着互联网的发展,我们已经越来越处于公开的信息的社会,笔者相信公开信息会越来越多,这也是社会整体利益所推动的。

从技术实现来看,系统中同时支持权限递加或递减可以带来配置的灵活性。

最后,强调一下,信息安全对于不同企业,哪怕他们处在同一行业,都是千变万化的;对于同一企业而言,不同时点的信息安全手段也是不同的;企业文化对信息安全管理的影响不可小觑。

作为IT安全人员,相信每一位都知道“知所必须”原则,结合“最小权限”的就是两个“最小化”原则,是很多IT安全人员在入门课上就学到的。怎样才是最小,相信也是IT安全人员一直孜孜追求的,很多人困惑于“如何将信息尽可能少的传递、权限尽可能小的授予,并能保证该岗位执行其正常工作。

首先,我们来看一个广为流传案例:“沃尔玛的任何一位员工,不论他/她的级别如何,如果获知其他地方卖的某样东西比沃尔玛便宜,他/她就有权把沃尔玛的同类商品进行降价”。这是一个授权,而这个权利对于很多企业来讲,非常“不小“。而沃尔玛的授权体系远不止如此,他们采取“店中店”的模式授权部门经理管理自己的业务,并认为信息共享的前提下,授权才会起到作用,因此沃尔玛的员工对采购价格、运输成本等数据(这些数据在很多企业被视为机密数据)都了如指掌的,难道沃尔玛不怕泄密事件的发生吗?

在此,笔者结合工作经验,来讲一些你所不知道的秘密。

应知的信息和应有的权限,是业务战略的结果。信息是为业务目标服务的,这一条是信息安全的基本定律,而很多信息安全人员在工作中却不知道或者忘记了这一基本定律,从信息安全去推导业务。从信息安全推导战略是一个错误的方向,信息安全需要结合行业特色、企业业务战略来制定,而不是采用僵化的所谓信息安全理论限制企业业务的发展。作为企业的管理层,更需要知道信息安全与业务战略之间的关系,并采取相应的风险管理策略。

信息的时效是信息安全的策略和手段需要重点关注的属性。例如:企业财务报告,尤其是上市公司的财务报告,被特定人群获知的时间点会影响其股票价格等因素,因此在某时点前是秘密,而在公开后必须保持持续可见性。

信息安全的属性是弹性的,与企业管理特色相关。例如:奖金信息,在某些企业是用来作为激励手段,只有公开了奖金信息,最少也应该分等级公开才能起到激励作用。随着互联网的发展,我们已经越来越处于公开的信息的社会,笔者相信公开信息会越来越多,这也是社会整体利益所推动的。

从技术实现来看,系统中同时支持权限递加或递减可以带来配置的灵活性。

最后,强调一下,信息安全对于不同企业,哪怕他们处在同一行业,都是千变万化的;对于同一企业而言,不同时点的信息安全手段也是不同的;企业文化对信息安全管理的影响不可小觑。