分类 观点 下的文章

编程可以给低收入家庭的学生提供足够的技能、信心和知识,进而让他们摆脱因为家庭收入低带来的经济和社会地位上的劣势。

尽管暑假期间底特律公共图书馆的帕克曼分部挤满了无聊的孩子并且占用了所有的电脑,图书馆工作人员并不觉得这会是个问题,反而更多是一个机会。他们成立一个名为 Parkman Coders 的编程社团,社团以 Qumisha Goss 为首,她是图书管理员,也负责利用 Python 的魔力引导弱势儿童的计算机思维。

四年前 Qumisha Goss 刚发起 Parkman Coders 计划的时候, “Q”(代表她)并不是太懂编程。之后她通过努力成为图书馆里教学和技术方面的专家和树莓派认证讲师。

社团最开始采用 Scratch 教学,但很快学生就对这种图形化的块编程感到乏味,他们觉得这就是个“婴儿玩具”。Q 坦言,“我们意识到是时候需要在课程内容这方面做些改变了,如果是为了维持课程内容对初学者的友好性继续选择 Scratch 教学,这无疑会影响孩子们后期继续保持对编程的关注。”因此,她开始教授孩子们 Python。

Q 是在 Code.org 平台玩地牢骷髅怪物这个关卡的时候第一次接触到 Python。她最开始是通过 《Python Programming: An Introduction to Computer Science》 和 《Python for Kids》 这两本书学习的 Python。她也推荐 《Automate the Boring Stuff with Python》 和 《Lauren Ipsum: A Story about Computer Science and Other Improbable Things》 这两本书。

建立一个基于树莓派的创客空间

Q 决定使用树莓派电脑来避免学生可能会因为自己的不当操作对图书馆的电脑造成损害,而且这些电脑因为便携性等问题也不方便用来构建组成一个创客空间。树莓派的购买价格加上它的灵活性和便携性包括生态圈里面的一些适合教学的自由免费软件,让大家更能感受到她的决策的可行性和可靠性。

虽然图书馆发起 Parkman Coders 社区计划的本意是通过努力创造一个吸引孩子们的学习空间,进而维持图书馆的平和,但社区发展的很快,很受大家欢迎,以至于这座建立于 1921 的大楼的空间,电脑和插座都不够用了。他们最开始是 20 个孩子共享 10 台树莓派来进行授课,但后来图书馆陆续收到了来自个人和公司比如 Microsoft、4H,和 Detroit Public Library Foundation 的资金援助从而能够购买更多设备以支撑社区的进一步壮大发展。

目前,每节课程大概有 40 个孩子参加,而且图书馆也有了足够的树莓派让参与者人手一台设备甚至还可以送出去一些。鉴于不少 Parkman Coders 的参与者来自于低收入家庭,图书馆也能提供别人捐赠的 Chromebooks 给他们使用。

Q 说,“当孩子们的表现可以证明他们能够很好的使用树莓派或者 Microbit 而且定期来参加课程,我们也会提供设备允许他们可以带回家练习。但即便这样也还是会遇到很多问题,比如他们在家无法访问网络或者没有显示器、键盘、鼠标等外设。”

利用 Python 学习生存技能,打破束缚

Q 说,“我认为教授孩子们计算机科学的主要目的是让他们学会批判性思考和解决问题的能力。我希望随着孩子们长大成人,不管他们选择在哪个领域继续发展他们的未来,这些经验教训都会一直伴随他们成长。此外,我也希望这个课程能够激发孩子们对创造的自豪感。能够清楚的意识到‘这是我做的’是一种很强烈、很有用的感受。而且一旦孩子们越早能够有这种成功的体验,我相信未来的路上他们都会满怀热情迎接新的挑战而不是逃避。”

她继续分享道,“在学习编程的过程中,你不得不对单词的拼写和大小写高度警惕。受限于孩子年龄,有时候阅读认知会是个大问题。为了确保课程受众的包容性,我们会在授课过程中大声拼读,同样我们也会极力鼓励孩子们大声说出他们不知道的或者不能正确拼写的单词,以便我们纠正。”

Q 也会尝试尽力去给需要帮助的孩子们更多的关注。她解释道,“如果我确认有孩子遇到困难不能跟上我们的授课进度,我们会尝试在课下时间安排老师辅导帮助他,但还是会允许他们继续参加编程。我们想帮助到他们而不是让他们因为挫败而沮丧的不再参与进来。”

最重要的是,Parkman Coders 计划所追求的是能够帮助每个孩子认识到每个人都会有独特的技能和能力。参与进来的大部分孩子都是非裔美国人,一半是女孩。Q 直言,“我们所生活在的这个世界,我们成长的过程中,伴随着各种各种的社会偏见,这些都常常会限制我们对自己所能达到的成就的准确认知。”她坚信孩子们需要一个没有偏见的空间,“他们可以尝试很多新事物,不会因为担心犯错责骂而束手束脚,可以放心大胆的去求知探索。”

Q 和 Parkman Coders 计划所营造的环境氛围能够帮助到参与者摆脱低家庭收入带来的劣势。如果说社区能够发展壮大到今天的规模真有什么独特秘诀的话,那大概就是,Q 解释道,“确保你有一个令人舒适的空间,充满了理解与宽容,这样大家才会被吸引过来。让来的人不忘初心,做好传道受业解惑的准备;当大家参与进来并感觉到充实愉悦,自然而然会想要留下来。”


via: https://opensource.com/article/19/2/break-down-stereotypes-python

作者:Don Watkins 选题:lujun9972 译者:WangYueScream 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

近日,笔者聆听了 VMware 大中华区高级技术总监李刚先生一场精彩演讲,他就企业 IT 的发展之路探讨了 VMware 企业云 2.0 的发展。

VMware 眼中的行业趋势

李刚谈到,从 VMware 的愿景可以看出整个企业 IT 正在发生的三个深刻的变化:

VMware 认为,首先,私有云演进为混合云,也就是说, 云基础架构可以自建也可以去当作服务购买,而提供给用户的是统一技术栈,统一运维管理的融合环境;其次,IT 和 CT 会融合成电信云~电信网络会形成云的形态;而边缘计算会成为一个新的基础架构形态。

从行业角度来看,也和 VMware 的愿景高度契合, VMware 称之为三波产业重大变革:

  • 第一个就是通过重构企业云,整个企业 IT 会全面转型以适应新的变化,拥抱变化创造新的机遇。当今的企业正处于从私有云和公有云阶段迈向混合云、多云的阶段,既保有了私有云的安全性,也利用到了公有云的开放性,使得企业可以以最佳成本获得业务快速发展的基础设施服务。而新的企业云,正承担着这一数字化转型的重任。
  • 第二个是云网融合,就是整个 IT 生态会以云和网络融合的形态来包容在企业的外围。在多云战略进一步深化之后,企业将协调处于多云环境中的数据、服务和应用,通过云和网络的融合,能将这些融为一体。未来,随着基础设施的进一步发展,流经多云之间的网络的流量必将占到更多的份额。
  • 第三个是拓展到边缘,边缘计算以后将会是更大的想象空间。越来越多的数据和应用将来自于边缘设备、迫切地需要在利用边缘设备的计算能力、存储能力以满足业务需求。这些迅速增长的边缘设备极大地拓展了计算的范围和领域,而它们的爆发式增长也给企业带来了更多压力和广阔的前景。

这三个变化和由此发展而来的三波浪潮,给企业计算带来全新的挑战和机遇,只有不断地变革企业云基础设施,升级企业的数字化技术,才能应对数字化转型 2.0 的进化,而这就是 VMware 重构企业云,推出企业云 2.0 的原动力。

重构企业云

VMware 认为,对于大中型企业而言,其战略方向无疑是重构企业云,通过建设新一代企业云(EnterpriseCloud 2.0),完成企业 IT 的重塑,让 IT 真正从资源供给的角色到创新平台的转变。

李刚谈到,所谓“重构企业云,实际上就是重构企业IT的核心,企业IT要做大的转型。用一句话来说,企业IT要从资源供给到创新平台。”

传统的企业,私有云的模式就是一个比较先进的企业IT模式了,但是私有云实际上关注的还是以资源为核心,而且做的主要工作就是两个:一个是资源池化,另一个是资源交付流程化和自动化。所有这些对业务来说的价值就是节省成本。对 IT 自身的价值是变得自动化简易和简单。

新一代企业云我们把它起个名字叫企业云 2.0。新一代企业云才会真正改变企业IT的形式、定位和价值。

企业云 2.0

什么是新一代企业云?李刚从四个方面阐述了这一概念:

第一,对于新一代企业云来说,它把资源转化成服务、而且是全栈式服务。所谓“全栈服务”就是说它,包括 IaaS、SaaS、PaaS 等完整的服务能力,企业IT要有能力提供各个层面的服务。这个叫全栈资源服务化

第二,从传统企业 IT 来说,用户的概念是相对比较弱的。传统企业 IT 严格意义上讲没有特别强烈的用户的概念——谁是你的用户,或者直接一点说,谁是你的云的用户?很多企业建了云,云的用户是谁?这个概念并没有得到强化。

在未来,对于企业云来说会有非常明显的用户的概念。

企业云的第一大用户就是你的业务创新团队,或研发团队。真正企业IT做的很好的,都已经大量的开始把研发从外包转向内包,甚至于能力的对外输出。第二类用户,即传统的业务线用户,当你的应用越来越丰富,也需要强化给用户提供服务的概念,而不是站在一个个单独的应用角度给用户提供服务,因为你的很多应用流程都会通过服务的方式提供出来,所以就有了所谓的应用门户的概念。这就是强化用户的概念

第三,新一代企业云里面不强调公有云、私有云,事实上,无论是公有云还是私有云都是你的资源。公有云和私有云只不过是你建设资源管理资源的一个方式和选择。至于怎么选有很多方面,比如安全性、可靠性、成本等等,此外还包括服务的种类。比如说现在公有云服务相对会比私有云多一些,有些服务在私有云上还没有建成,需要公有云提供支持。而这些都是你的资源。最重要的是,要能够融合资源,以安全可控可管理的方式为我所用。

第四个,云本身具有非常强烈的迭代发展的概念,并不像传统的数据中心建设有一期、二期那么明确的阶段性。云服务必须不断的推出、升级,要能积淀这些服务,让它能力不断的增强。

企业 IT 演进战略

谈及了企业云 2.0,就不能不提到企业IT演进战略,李刚把它分成三个方面进行了阐述:云战略、服务战略、应用战略。

所谓云战略,就是把基础架构往前推,包括私有云跟同构公有云如何在资源上做分配,原生公有云和公有云之间如何做整合,企业应用怎么上云,公有云的技术怎么导入企业 IT 等等,这是讲云的战略。

其次是服务战略,之前它的服务非常弱化,在企业云 2.0 的实际建设里,最核心的部分之一就是怎么样把这些资源变成服务,提供给开发团队,这是很重要的能力。

第三是应用战略,就是应用怎么变得敏捷、创新,从外包到内包,怎么去思考这些问题。之前在这个层面上做的很多工作都是在建设一个传统的池化资源,采用私有云的模式。而到了企业云 2.0 阶段,从应用来看就是怎么定位你的应用,哪些应用可以退出了,哪些应用可以重新放在云上,哪些应用不用理它,哪些应用重新按照新的模式做设计,你的应用开发模式要做转变。

基础架构即代码

当你开始架构你的应用的时候,同时也会规划基础架构怎么部署,而且是代码的方式进行规划和部署。在真实部署之前会做配置管理,然后采用基础架构代码的方式来管理。在每一步,当你需要基础架构提供支持的时候,它会帮你部署和调整基础架构,这里是由代码自动提供的。

这个基础架构的概念包括 IaaS、PaaS 等,包括各种各样的服务。通过在企业内部实现企业云 2.0,知道企业内部有哪些资源可供被调用,然后把来自不同云的、包括私有云的这些服务组装成企业所需要的基础架构的元配件,再用代码的方式编写成应用所需要的基础架构描述,然后,研发团队会自动的调用这些代码生成基础架构。一个真正的应用,比如 VMware公司 内部在做的云管产品的应用,每天会做几十次的持续集成、自动化测试和持续交付,整个的迭代速度非常快,发现错误的速度也非常快,整个开发的进度就是之前十几倍、几十倍的提升。

这里有个非常核心的部分,第一个,你会发现它充分体现了应用驱动,应用在驱动整个基础架构在变动。第二点,这些如果不是软件定义的,不是真正可以代码化的,应用根本没法驱动,它需要完全高度代码化,然后就可以通过应用驱动转起来了。所以,在软件定义之上,有了应用驱动,使得价值充分发挥出来,IT基础架构变得高度灵活。

与 Intel 携手

而李刚先生在演讲中也提及,VMware 行业领先的云计算技术和 Intel® 技术可以帮助客户充分利用混合云,并连接和管理本地部署与远程部署的工作负载,从而提高敏捷性、容量、透明度、可见性和恢复能力。

借助一系列私有云、公有云和混合云解决方案,企业可以随心所欲地实施支持其云计算战略的云计算解决方案,以推动其独特业务的发展。他们既可以自由选择,又能保持可控力。

云的未来

早在 2015 年时,VMware 发布的企业愿景“一云承万象”,其核心是通过软件定义的基础设施,在一体化的混合云平台上,支持任何类型的应用和对不同类型的终端平台做交付服务。如今, VMware 的这一愿景得到了再次升华,在迎合新的变化的同时,深耕于企业云计算领域,也将自身转化为了一家“数字技术基础设施”供应商。而新的企业云 2.0 也正是这家软件巨头向未来迈出的坚实一步。

系统管理员和网站可靠性工程师(SRE,下同)对于任何组织来讲都很重要。本篇将介绍下两者的不同之处。

在 IT 行业,成为多面手或是专家的争议一直存在。99% 的传统系统管理员都被归到了多面手这类。 网站可靠性工程师 site reliability engineer (SRE)的角色则更加专精,并且在如 Google 般有着一定规模的头部公司中对其的需求不断增加。但总的来说这两者对于跑着应用的基础设施有着同样的目标:为应用的消费者提供良好的体验。然而两者的出发点却截然不同。

系统管理员:中立善良的化身

系统管理员一般都是从基础的桌面或网络支持成长过来的,并一路习得大多数系统管理员都会掌握的广泛的技能。此时这些系统管理员会对他们所负责的系统和应用了如指掌。他们会知道一号服务器上的应用每隔一个星期二就需要重启一次,或是九号服务器周三会静默的崩溃。他们会对服务器的监视作出微调以忽略无关紧要的信息,尽管那个被标记为 致命 fatal 的错误信息每个月第三个周日都会显示。

总的来讲,系统管理员了解如何照料那些跑着你核心业务的服务器。这些系统管理员已经成长到开始使用自动化工具去处理所有归他们管的服务器上的例行任务。他们虽然喜欢使用模板、 黄金镜像 golden images 、以及标准,但同时也有着足够的灵活度去修改一个服务器上的参数以解决错误,并注释为什么那个服务器的配置与众不同。

尽管系统管理员很伟大,但他们也有着一些怪癖。其中一项就是没有他们神圣的授权你永远也获取不了系统的 root 访问权限,另一项则是任何不是出于他们的主意的变更都要在文档中被记录为应用提供方的要求,并仍然需要再次核对。

他们所管理的服务器是他们的地盘,没有人可以随意干涉。

SRE:灭霸将为之自豪

与成为系统管理员的道路相反,从开发背景和从系统管理员背景成长为 SRE 的可能性相近。SRE 的职位出现的时长与应用开发环境的生命周期相近。

随着一个组织的发展而引入的类似于持续集成持续发布 (CI/CD) 的 DevOps 概念,通常会出现技能空缺,以让这些 不可变 immutable 的应用部署到多个环境并随着业务需求进行扩展。这将是 SRE 的舞台。的确,一个系统管理员可以学习额外的工具,但大体上成为一个全职的职位更容易跟的上发展。一个专精的专家更有意义。

SRE 使用如 代码即基础设施 infrastructure-as-code 的概念去制作模板,然后调用它们来部署用以运行应用的环境,并以使用一键完整重现每个应用和它们的环境作为目标。因此会出现这样的情况:测试环境中一号服务器里的一号应用的二进制文件与生产环境中十五号服务器的完全一致,仅环境相关的变量如密码和数据库链接字串有所不同。

SRE 也会在配置发生改变时完全销毁一个环境并重新构建它。对于任何系统他们都不带一点感情。每个系统只是个被打了标记和安排了生命周期的数字而已,甚至连例行的对服务器打补丁也要重新部署整个 应用栈 application stack

总结

对于一些情况,尤其是运维一些大型的基于 DevOps 的环境时,一个 SRE 所能提供的用于处理各种规模的业务的专业技能当然更具优势。但每次他们在运气不好走入死胡同时都会去寻求他的系统管理员友人或是 来自地狱的混蛋运维(BOFH) ,得到他那身经百战的故障排除技能,和那些用于给组织提供价值的丰富经验的帮助。


via: https://opensource.com/article/19/7/sysadmins-vs-sres

作者:Vince Power 选题:lujun9972 译者:vizv 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

创新是一种混乱的过程,但是关于创新的故事却很有条理。我们不应该把两者搞混了。

如果说 传统的规划方法已经消亡了,为什么这么多机构还在孜孜不倦地运用那些针对工业革命所设计的规划方法呢?

其中的一个原因是,我们错误地认为创新是可以通过结构化的、线性的过程实现的。我觉得这样做是在混淆关于创新的 故事 和创新这个 过程 本身 —— 两者是截然不同的东西。

创新的过程是混乱和不可预测的,并不遵循井然有序的时间线。过程中充满了重复迭代、突然的改变方向、各式各样的启动和终止、死胡同、失败(但愿是有用的失败),以及很多不可知的变量。创新是混乱的。

但是关于创新的故事却让事情显得很简单,从讲述伟大发明的书籍和文章,到我们(简化了整个过程之后)讲述自己在工作上的成功都是这样。想想你在社交媒体上读的帖子里,有多少都只写了最好的、最愉快的部分吧。

好故事就是这样。我们把一些原本分散的时间点干净利落地整理到一起,有开头、有发展、也有结尾。尽管我们一路上经历了很多没有把握、恐慌、甚至是绝望的时刻,在故事里这些坎坷却都被抹平了,让事情看起来像是从一开始就注定是成功的。

我们不应该把混乱的过程和简化了的故事搞混。否则,我们会错误地认为可以使用在简单线性过程中所使用的同样的方法迎接创新的挑战。换句话说,我们将适用于一种类型的活动(比较偏死记硬背、机械和规则性的任务)的管理技术应用在了并不适用的另一种类型的活动(更加有创造性的、非线性的工作,需要自主性和试验)上。

一个创新的故事

下面这个故事可以很好地说明这一点。这是我 最喜欢举的例子 之一。

在 1970 年代,英国的摩托车行业怎么也想不明白为什么他们在美国的市场份额急剧下降,而本田公司的市场份额却急速攀升。他们雇佣了波士顿咨询公司(刚好是我之前的雇主)帮助他们找出问题所在。波士顿咨询搜集了一些历史数据,回看了二十年的历史事件,总结出了一个井井有条的、线性的故事,可以很好地解释本田公司的成功。

波士顿咨询的结论是,本田公司使用了一个巧妙的策略:通过一种可以以更低价格销售的偏小型摩托车进入美国市场,并且借助于他们在日本本土市场发展出来的规模经济,在美国市场使用低价策略发展市场份额,然后等到需求进一步增长的时候,再利用更大的规模经济发展他们在美国的市场份额。在所有人的眼中,本田公司都表现得非常出色,不仅发挥了自己的优势,还非常透彻和精准地理解了新的目标顾客:美国消费者。他们智胜一筹,通过一个执行得很好的计划占领了先机,胜过了竞争对手们。

这个故事 听上去 很厉害,但是实际情况没有这么简单。

没错,本田公司 确实 是想进入美国摩托车市场。他们最初是想 效仿在美国的竞争对手,也制造美国人似乎更喜欢的大型摩托车。但是大型摩托车并不是本田公司的强项,他们生产的大型摩托车存在可靠性上的问题。更糟的是,他们的产品和市面上的其它产品没有什么差别,所以并不能脱颖而出。简单来说,他们的产品销售额表现平平。

但是在一次奇妙的巧合里,本田公司出访美国的日本代表们带了几辆自己开的摩托车。这些摩托车和本田公司试图在美国市场上销售的摩托车完全不同,它们更为小巧灵活、不那么笨重、更有效率,并且一般来说也更便宜。西尔斯公司(LCTT 译注:美国零售业巨头)注意到了这些小巧的摩托车,并且和日本代表达成了一项协议,让西尔斯公司可以在他们在美国的商店里出售这种被称为“超级幼兽”的新型摩托车。

剩下的故事已经载入史册。超级幼兽成为了 史上最畅销的机动车,并且本田公司 至今仍然在生产超级幼兽

事后看来,将超级幼兽带到美国的一连串事件似乎很有逻辑,近乎无聊了。但是本田公司的成功和“巧妙的计划”没有什么关系,而更应该归功于一些(大多数人不愿意承认的)机缘巧合。

开放(并且混乱的)创新

机构(特别是领导们)喜欢把成功说成是一件计划之内的事情 —— 好像成功人士可以驾驭混乱,并且几乎可以预测未来。但是这些言论都是事后诸葛亮罢了,他们在讲述自己充满偶然性的经历的时候会刻意将无序的事情整理一番,对于毫无确定性的事情也会说“我们就是想要那么做的”。

但是正如我前面说的,我们不应该相信这些故事是创新过程的真实还原,也不应该在这种错误的假设的基础之上去构建未来的方案或者实验。

试想有另一家摩托车制造商想要复制本田公司在超级幼兽上的成功,就逐字逐句地照搬波士顿咨询总结的故事。由于本田公司成功的 故事 听上去是如此有逻辑,并且是线性的,这家新公司也许会假定他们可以通过类似的程序得到同样的结果:制定目标、谋划行动,然后针对可预期的结果进行执行。但是我们知道本田公司并不是真的靠这种“制定、谋划、执行”的方式赢得他们的市场份额的。他们是通过灵活性和一点运气获得成功的 —— 更像是“尝试、学习、修改”。

当我们可以真正理解并且接受“创新过程是混乱的”这个事实的时候,我们就可以换种方式思考如何让我们的机构实现创新了。与其将资源浪费在预先制定的计划上,强迫 创新以一种线性时间线的方式发生,我们不如去构建一些开放并且敏捷的机构,可以 在创新发生的时候做出及时的响应

几年前红帽公司发布一个包含了重大技术升级的产品的新版本的时候,我就看到了这样的方法。红帽企业级 Linux 5.4 版本 首次完全支持了一种被称为基于内核的虚拟机(KVM)的技术。这对于我们来说是一个重大的创新,不仅可以为顾客和合作伙伴带来巨大的价值,也有望为开源社区带来巨大的价值。

这项技术正在快速演进。幸运的事,因为我们是一个开放的机构,我们具有足够的适应能力,可以在这项创新发生的时候做出响应,从而帮助我们的顾客和合作伙伴可以更好地利用它。这项技术太重要了,并且竞争格局也太不稳定了,以至于我们没有理由要等到像 6.0 版本这样的里程碑时刻才出手。

如果你回看红帽企业级 Linux 已经存档的发行说明,你会发现它读起来并不像一个典型的软件创新的故事。一次改变游戏规则的进展突然出现在一个没有预测到的、并不起眼的时刻(5.4 版本),而不是一个事先计划好的重要里程碑时刻(6.0 版本)。事后看来,我们现在知道 KVM 这种“大爆炸”级别的进步是足够担得起 “6.0 版本”这样的里程碑式的名字的。但是创新并不是按照这样的剧本发生的。

不要误解我,机构仍然需要保持出色的运转,高效完成执行性的任务。但是 不同的挑战需要不同的方法去应对,我们需要能够更好地建立灵活的机构,以及对 意想不到和不可知的事情 能够做出更好的响应。

一个在计划工作(以及按照计划执行)上做得很出色的公司很可能会得到他们计划要得到的结果。但是如果成功还取决于我们没有预测或者无法预测的的事情,那么仅仅精准地按照计划执行是不是就不够了?


via: https://opensource.com/open-organization/19/6/innovation-delusion

作者:Jim Whitehurst 选题:lujun9972 译者:chen-ni 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

DevSecOps 的实践之旅开始于 DevSecOps 增权、赋能和培养。下面就介绍如何开始学习使用 DevSecOps。

Stephen Streichsbier 说过: DevSecOps 使得组织可以用 DevOps 的速度发布内在安全的软件。

DevSecOps 是一场关于 DevOps 概念实践或艺术形式的变革。为了更好理解 DevSecOps,你应该首先理解 DevOps 的含义。

DevOps 起源于通过合并开发和运维实践,消除隔离,统一关注点,提升团队和产品的效率和性能。它是一种注重于构建容易维护和易于平常自动运营的产品和服务的新型协作方式。

安全在很多团队中都是常见的隔离点。安全的核心关注点是保护团队,而有时这也意味着创建延缓新服务或是新产品发布的障碍或策略,用于保障任何事都能被很好的理解和安全的执行,并且没有给团队带来不必要的风险。

因为安全隔离点方面的明显特征和它可能带来的摩擦,开发和运维有时会避开安全要求以满足客观情况。在一些公司,这种隔离形成了一种产品安全完全是安全团队责任的期望,并取决于安全团队去寻找产品的安全缺陷或是可能带来的问题。

DevSecOps 看起来是通过给开发或是运维角色加强或是建立安全意识,或是在产品团队中引入一个安全工程师角色,在产品设计中找到安全问题,从而把安全要求汇聚在 Devops 中。

这样使得公司能更快发布和更新产品,并且充分相信安全已经嵌入产品中。

坚固的软件哪里适用 DevSecOps?

建造坚固的软件是 DevOps 文化的一个层面而不是一个特别的实践,它完善和增强了 DevSecOps 实践。想想一款坚固的软件就像是某些经历过残酷战斗过程的事物。

有必要指出坚固的软件并不是 100% 安全可靠的(虽然它可能最终是在某些方面)。然而,它被设计成可以处理大部分被抛过来的问题。

践行坚固软件最重要的原则是促进竞争、实践、可控的失败与合作。

你该如何开始学习 DevSecOps ?

开始实践 DevSecOps 涉及提升安全需求和在开发过程中尽可能早的阶段进行实践。它最终在公司文化上提升了安全的重要性,使得安全成为所有人的责任,而并不只是安全团队的责任。

你可能在团队中听说过“ 左上升 shift left ”这个词,如果你把开发周期线扁平化到一条横线上,以包括产品变革的的关键时期:从初始化到设计、建造、测试以及最终的运行,安全的目的就是尽早的参与进来。这使得风险可以在设计中能更好的评估、交流和减轻。“左提升”的含义是指促使安全能在开发周期线上更往左走。

这个过程始于三个关键要素:

  • 增权 empowerment
  • 赋能 enablement
  • 培养 education

增权,在我看来,是关于释放控制权以及使得团队(在理性分析下)做出独立决定而不用害怕失败或影响。这个过程的唯一告诫信息就是要严格的做出明智的决定(不要比这更低要求)。

为了实现增权,商务和行政支持(通过内部销售、展示来建立,通过建立矩阵来展示这项投资的回报)是打破历史障碍和割裂的团队的关键。合并安全人员到开发和运维团队中,提升交流和透明度有助于开始 DevSecOps 之旅。

这个整合和移动使得团队只关注单一的结果:打造一个他们共同负责的产品,让开发和安全人员相互依赖合作。这将引领你们共同走向增权。这是产品研发团队的共同责任,并保证每个可分割的产品都保持其安全性。

赋能涉及正确的使用掌握在团队手中的工具和资源。这是建立一种通过论坛、维基、信息聚合的知识分享文化。

打造一种注重自动化、重复任务应该编码来尽可能减少以后的操作并增强安全性的理念。这种场景不仅仅是提供知识,而是让这种知识能够通过多种渠道和媒介(通过某些工具)可获取,以便它可以被团队或是个人以他喜欢的方式去消化和分享。当团队成员正在编码时一种媒介可能工作的很好,而当他们在进行中时另一种可能更好。让工具简单可用,让团队用上它们。

不同的 DevSecOps 团队有不同的喜好,因此允许他们尽可能的保持独立。这是一个微妙的平衡工作,因为你确实希望实现规模经济和产品间共享的能力。在选择中协作和参与,并更新工具方法有助于减少使用中的障碍。

最后,也可能是最重要的,DevSecOps 是有关训练和兴趣打造。聚会、社交或是组织中通常的报告会都是让同事们教学和分享他们的知识的很棒的方式。有时,这些会突出其他人可能没有考虑过的共同挑战、顾虑或风险。分享和教学也是一种高效的学习和指导团队的方法。

在我个人经验中,每个团队的文化都是独一无二的,因此你不能用一种“普适”的方法。走进你的团队并找到他们想要使用的工具方法。尝试不同的论坛和聚会并找出最适用于你们文化的方式。寻找反馈并询问团队如何工作,他们喜欢什么以及对应的原因。适应和学习,保持乐观,不要停止尝试,你们将会有所收获。


via: https://opensource.com/article/19/1/what-devsecops

作者:Brett Hunoldt 选题:lujun9972 译者:PandaWizard 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Aruba 战略和企业发展副总裁 Jeff Lipton 为 5G 炒作增添了一些干货,讨论了它和 Wi-Fi 如何协同工作以及如何最大化两者的价值。

如今可以说没有技术主题比 5G 更热。这是最近 移动世界大会 节目的一个主题,并且已经在其他活动中占据了主导地位,例如 Enterprise Connect 和我参加的几乎所有供应商活动。

一些供应商将 5G 定位为解决所有网络问题的灵丹妙药,并预测它将消除所有其他形式的网络。像这样的观点显然是极端的,但我相信 5G 会对网络行业产生影响,网络工程师应该意识到这一点。

为了帮助为 5G 炒作带来一些现实感,我最近采访了一家惠普公司旗下的 Aruba 公司的战略和企业发展副总裁 Jeff Lipton,因为我知道惠普已经深入参与了 5G 和 Wi-Fi 的发展。

Zeus Kerravala: 5G 被吹捧为“明日之星”。你是这样看的吗?

Jeff Lipton: 接下来的重点是连接“事物”并从这些事物中产生可操作的见解和背景。5G 是服务于这一趋势的技术之一。Wi-Fi 6 是另一个,还有边缘计算、蓝牙低功耗(BLE)、人工智能(AI)和机器学习(ML)。这一切都很重要,全都有自己的用武之地。

你是否在企业中看到 5G 的风头盖过 Wi-Fi?

Lipton: 与所有蜂窝接入一样,如果你需要 宏观区域覆盖 macro area coverage 和高速切换,使用 5G 是合适的。但对于大多数企业级应用程序而言,它通常不需要这些功能。从性能角度来看,Wi-Fi 6 和 5G 在大多数指标上大致相等,包括吞吐量、延迟、可靠性和连接密度。它们并不相似的地方在经济方面,Wi-Fi 要好得多。我不认为很多客户愿意用 Wi-Fi 交换 5G,除非他们需要宏观覆盖或高速切换。

Wi-Fi 和 5G 可以共存吗? 企业如何一起使用 5G 和 Wi-Fi?

Lipton: Wi-Fi 和 5G 可以共存并且应该是互补的。5G 架构将蜂窝核心和无线接入网络(RAN)分离。因此,Wi-Fi 可以是企业无线电前端,并与 5G 核心紧密连接。由于 Wi-Fi(特别是 Wi-Fi 6)的经济有利,并且性能非常好,我们设想许多服务提供商会使用 Wi-Fi 作为其 5G 系统的无线电前端,充当其分布式天线(DAS)和小型蜂窝系统的替代方案。

“Wi-Fi 和 5G 可以并且应该是互补的。” — Jeff Lipton

如果一个企业打算完全转向 5G,那将如何实现以及它的实用性如何?

Lipton: 为了将 5G 用于主要的室内访问方式,客户需要升级其网络和几乎所有设备。5G 在室外提供良好的覆盖,但蜂窝信号不能可靠地穿透建筑物,5G 会使这个问题变得更糟,因为它部分依赖于更高频率的无线电。因此,服务提供商需要一种提供室内覆盖的方法。为了提供这种覆盖,他们会部署 DAS 或小型蜂窝系统 —— 由终端客户支付费用。然后,客户将他们的设备直连到这些蜂窝系统,并为每个设备支付服务合同。

这种方法存在一些问题。首先,DAS 和小型蜂窝系统比 Wi-Fi 网络贵得多。并且成本不会仅限于网络。每台设备都需要一台 5G 蜂窝调制解调器,批量价格高达数十美元,而终端用户通常需要花费一百多美元。由于目前很少或者没有 MacBook、PC、打印机、AppleTV 有 5G 调制解调器,因此需要对这些设备进行升级。我不相信很多企业会愿意支付这笔额外费用并升级他们的大部分设备以获得尚不明确的好处。

经济性是 5G 与 Wi-Fi 之争的一个要素吗?

Lipton: 经济性始终是一个要素。让我们将对话集中在室内企业级应用程序上,因为这是一些运营商打算用 5G 定位的用例。我们已经提到升级到 5G 将要求企业部署昂贵的 DAS 或小型蜂窝系统用于室内覆盖,几乎将所有设备升级到包含 5G 调制解调器,并为每个设备支付服务合同。理解 5G 蜂窝网络和 DAS 系统在许可频谱上运行也很重要,这类似于一条私人高速公路。服务提供商为此频谱支付了数十亿美元,这笔费用需要货币化并嵌入服务成本中。因此,从部署和生命周期的角度来看,Wi-Fi 在经济上比 5G 有利。

5G 与 Wi-Fi 相比有任何安全隐患吗?

Lipton: 一些人认为蜂窝技术比 Wi-Fi 更安全,但事实并非如此。LTE 相对安全,但也有弱点。例如,普渡大学和爱荷华大学的研究人员表示,LTE 容易受到一系列攻击,包括数据拦截和设备跟踪。5G 通过多种认证方法和更好的密钥管理改进了 LTE 安全性。

Wi-Fi 的安全性也没有停滞不前而是在继续发展。当然,不遵循最佳实践的 Wi-Fi 实现,例如那些甚至没有基本密码保护的实现,并不是最佳的。但那些配置了适当的访问控制和密码的则是非常安全的。随着新标准 —— 特别是 WPA3 和 增强开放 Enhanced Open —— Wi-Fi 网络安全性进一步提高。

同样重要的是要记住,企业已根据其特定需求对安全性和合规性解决方案进行了大量投资。对于包括 5G 在内的蜂窝网络,企业将失去部署所选安全性和合规性解决方案的能力,以及对流量流的大多数可见性。虽然 5G 的未来版本将通过称为网络切片的功能提供高级别的自定义,但企业仍将失去他们目前需要的和拥有的安全性和合规性定制级别。

关于 5G 与 Wi-Fi 之间的讨论的补充想法

Lipton: 围绕 Wi-Fi 与 5G 的争论忽略了这一点。它们都有自己的用武之地,而且它们在很多方面都是互补的。由于需要连接和分析越来越多的东西,Wi-Fi 和 5G 市场都将增长。如果客户需要宏观覆盖或高速切换,并且可以为这些功能支付额外成本,那么 5G 是可行的。

5G 也适用于客户需要物理网络分段的某些工业用例。但对于绝大多数企业客户而言,Wi-Fi 将继续像现在一样证明自己作为可靠、安全且经济高效的无线接入技术的价值。

更多关于 802.11ax (Wi-Fi 6):


via: https://www.networkworld.com/article/3399978/5g-will-augment-wi-fi-not-replace-it.html

作者:Zeus Kerravala 选题:lujun9972 译者:GraveAccent 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出