DevSecOps 也许不是一个优雅的词汇，但是其结果很吸引人：更强的安全、提前出现在开发周期中。来看看一个 IT 领导与 Meltdown 的拼搏。

如果 DevOps 最终是关于创造更好的软件，那也就意味着是更安全的软件。

而到了术语 “DevSecOps”，就像任何其他 IT 术语一样，DevSecOps —— 一个更成熟的 DevOps 的后代 ——可能容易受到炒作和盗用。但这个术语对那些拥抱了 DevOps 文化的领导者们来说具有重要的意义，并且其实践和工具可以帮助他们实现其承诺。

说道这里：“DevSecOps”是什么意思？

“DevSecOps 是开发、安全、运营的混合，”来自 Datical 的首席技术官和联合创始人 Robert 说。“这提醒我们，对我们的应用程序来说安全和创建并部署应用到生产中一样重要。”

想阅读其他首席技术官的 DevOps 文章吗？查阅我们丰富的资源，[DevOps：IT 领导者指南]

向非技术人员解释 DevSecOps 的一个简单的方法是：它是指将安全有意并提前加入到开发过程中。

“安全团队从历史上一直都被孤立于开发团队——每个团队在 IT 的不同领域都发展了很强的专业能力”，来自红帽安全策的专家 Kirsten 最近告诉我们。“不需要这样，非常关注安全也关注他们通过软件来兑现商业价值的能力的企业正在寻找能够在应用开发生命周期中加入安全的方法。他们通过在整个 CI/CD 管道中集成安全实践、工具和自动化来采用 DevSecOps。”

“为了能够做的更好，他们正在整合他们的团队——专业的安全人员从开始设计到部署到生产中都融入到了开发团队中了，”她说，“双方都收获了价值——每个团队都拓展了他们的技能和基础知识，使他们自己都成更有价值的技术人员。 DevOps 做的很正确——或者说 DevSecOps——提高了 IT 的安全性。”

IT 团队比任何以往都要求要快速频繁的交付服务。DevOps 在某种程度上可以成为一个很棒的推动者，因为它能够消除开发和运营之间通常遇到的一些摩擦，运营一直被排挤在整个过程之外直到要部署的时候，开发者把代码随便一放之后就不再去管理，他们承担更少的基础架构的责任。那种孤立的方法引起了很多问题，委婉的说，在数字时代，如果将安全孤立起来同样的情况也会发生。

“我们已经采用了 DevOps，因为它已经被证明通过移除开发和运营之间的阻碍来提高 IT 的绩效，”Reevess 说，“就像我们不应该在开发周期要结束时才加入运营，我们不应该在快要结束时才加入安全。”

为什么 DevSecOps 必然出现

或许会把 DevSecOps 看作是另一个时髦词，但对于安全意识很强的IT领导者来说，它是一个实质性的术语：在软件开发管道中安全必须是第一层面的要素，而不是部署前的最后一步的螺栓，或者更糟的是，作为一个团队只有当一个实际的事故发生的时候安全人员才会被重用争抢。

“DevSecOps 不只是一个时髦的术语——因为多种原因它是现在和未来 IT 将呈现的状态”，来自 [Sumo Logic] 的安全和合规副总裁 George 说道，“最重要的好处是将安全融入到开发和运营当中开提供保护的能力”

此外，DevSecOps 的出现可能是 DevOps 自身逐渐成熟并扎根于 IT 之中的一个征兆。

“企业中的 DevOps 文化已成定局，而且那意味着开发者们正以不断增长的速度交付功能和更新，特别是自我管理的组织会对合作和衡量的结果更加满意”，来自 [CYBRIC] 的首席技术官和联合创始人 Mike 说道。

在实施 DevOps 的同时继续保留原有安全措施的团队和公司，随着他们继续部署的更快更频繁可能正在经历越来越多的安全管理风险上的痛苦。

“现在的手工的安全测试方法会继续远远被甩在后面。”

“如今，手动的安全测试方法正被甩得越来越远，利用自动化和协作将安全测试转移到软件开发生命周期中，因此推动 DevSecOps 的文化是 IT 领导者们为增加整体的灵活性提供安全保证的唯一途径”，Kail 说。

转移安全测试也使开发者受益：他们能够在开放的较早的阶段验证并解决潜在的问题——这样很少需要或者甚至不需要安全人员的介入，而不是在一个新的服务或者更新部署之前在他们的代码中发现一个明显的漏洞。

“做的正确，DevSecOps 能够将安全融入到开发生命周期中，允许开发者们在没有安全中断的情况下更加快速容易的保证他们应用的安全”，来自 SAS 的首席信息安全员 Wilson 说道。

Wilson 指出静态（SAST）和源组合分析（SCA）工具，集成到团队的持续交付管道中，作为有用的技术通过给予开发者关于他们的代码中的潜在问题和第三方依赖中的漏洞的反馈来使之逐渐成为可能。

“因此，开发者们能够主动和迭代的缓解应用安全的问题，然后在不需要安全人员介入的情况下重新进行安全扫描。” Wilson 说。他同时指出 DevSecOps 能够帮助开发者简化更新和打补丁。

DevSecOps 并不意味着你不再需要安全组的意见了，就如同 DevOps 并不意味着你不再需要基础架构专家；它只是帮助你减少在生产中发现缺陷的可能性，或者减少导致降低部署速度的阻碍，因为缺陷已经在开发周期中被发现解决了。

“如果他们有问题或者需要帮助，我们就在这儿，但是因为已经给了开发者他们需要的保护他们应用安全的工具，我们很少在一个深入的测试中发现一个导致中断的问题，”Wilson 说道。

DevSecOps 遇到 Meltdown

Sumo Locic 的 Gerchow 向我们分享了一个在运转中的 DevSecOps 文化的一个及时案例：当最近 [Meltdown 和 Spectre] 的消息传来的时候，团队的 DevSecOps 方法使得有了一个快速的响应来减轻风险，没有任何的通知去打扰内部或者外部的顾客，Gerchow 所说的这点对原生云、高监管的公司来说特别的重要。

第一步：Gerchow 的小型安全团队都具有一定的开发能力，能够通过 Slack 和它的主要云供应商协同工作来确保它的基础架构能够在 24 小时之内完成修复。

“接着我的团队立即开始进行系统级的修复，实现终端客户的零停机时间，不需要去开工单给工程师，如果那样那意味着你需要等待很长的变更过程。所有的变更都是通过 Slack 的自动 jira 票据进行，通过我们的日志监控和分析解决方案”，Gerchow 解释道。

在本质上，它听起来非常像 DevOps 文化，匹配正确的人员、过程和工具，但它明确的将安全作为文化中的一部分进行了混合。

“在传统的环境中，这将花费数周或数月的停机时间来处理，因为开发、运维和安全三者是相互独立的”，Gerchow 说道，“通过一个 DevSecOps 的过程和习惯，终端用户可以通过简单的沟通和当日修复获得无缝的体验。”

via: https://enterprisersproject.com/article/2018/1/why-devsecops-matters-it-leaders

作者：Kevin Casey 译者：FelixYFZ 校对：wxy

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

想要在你的自动化项目上达成强 ROI？采取如下步骤来规避失败。

在过去的几年间，有关自动化技术的讨论已经很多了。COO 们和运营团队（事实上还有其它的业务部门）对于可以重新定义成本随着工作量的增加而增加的这一事实而感到震惊。

机器人流程自动化 Robotic Process Automation （RPA）似乎预示着运营的 圣杯 Holy Grail ：“我们提供了开箱即用的功能来满足你的日常操作所需 —— 检查电子邮件、保存附件、取数据、更新表格、生成报告、文件以及目录操作。构建一个机器人就像配置这些功能一样简单，然后用机器人将这些操作链接到一起，而不用去请求 IT 部门来构建它们。”这是一个多么诱人的话题。

低成本、几乎不出错、非常遵守流程 —— 对 COO 们和运营领导来说，这些好处真实可及。RPA 工具承诺，它从运营中节省下来的费用就足够支付它的成本（有一个短的回报期），这一事实使得业务的观点更具有吸引力。

自动化的谈论都趋向于类似的话题：COO 们和他们的团队想知道，自动化操作能够给他们带来什么好处。他们想知道 RPA 平台特性和功能，以及自动化在现实中的真实案例。从这一点到概念验证的实现过程通常很短暂。

在实现人工智能技术方面的建议，可以查看我们相关的文章，[制定你的人工智能策略：3 个小提示]。

但是自动化带来的现实好处有时候可能比你所预期的时间要晚。采用 RPA 的公司在其实施后可能会对它们自身的 ROI 提出一些质疑。一些人没有看到预期之中的成本节省，并对其中的原因感到疑惑。

你是不是自动化了错误的东西？

在这些情况下，自动化的愿景和现实之间的差距是什么呢？我们来分析一下它，在决定去继续进行一个自动化验证项目（甚至是一个成熟的实践）之后，我们来看一下通常会发生什么。

在确定实施自动化所采用的路径之后，COO 一般会问运营领导和他的团队们，应该在哪个流程或者任务上实施自动化。虽然从原则上说应该鼓励他们参与进来，但是有时候这种方式产生的决策往往会产生一个次优选择。原因如下：

首先，团队领导经常会是“视野较窄”：他们对自己的流程和任务非常熟悉，但是对他们不参与的流程和任务并不是那么熟悉（特别是在他们没有太多运营经验的情况下）。这意味着他们在自己的工作领域内可能会找出比较适合自动化的候选者，但是在跨整个运营的其它领域中可能并不一定会找出最适合的。另外其它的像“我希望我的流程成为第一个实施自动化的候选者”这样的“软性”因素也会影响决定。

其次，候选流程的选择有时候会被自动化特性和能力的匹配度所支配，而不是根据自动化所带来的价值所决定的。一个常见的误解是，任何包括像电子邮件或目录监视、下载、计算等活动的任务都是自动化的最佳候选者。如果对这些任务实施自动化不能为组织产生价值，那么它们就不是正确的候选者。

那么，对于领导们来说，怎么才能确保实施自动化能够带来他们想要的 ROI 呢？实现这个目标有四步：

1. 教育团队

在你的团队中，从 COO 职位以下的人中，很有可能都听说过 RPA 和运营自动化。同样很有可能他们都有许多的问题和担心。在你开始启动实施之前解决这些问题和担心是非常重要的。

对运营团队进行积极的教育可以大大地提升他们对自动化的热情和信心。培训主要关注于自动化和机器人是什么，它们在流程中一般扮演什么样的角色，哪个流程和任务最适合自动化，以及自动化的预期好处是什么。

建议：邀请你的自动化合作伙伴去进行这些团队教育工作，你要有所控制：他们可能会非常乐意帮助你。在领导层将这些传播到更大范围的团队之前，你应该对他们的教育内容进行把关。

“实施自动化的第一步是更好地理解你的流程。”

2. 审查内部流程

实施自动化的第一步是更好地理解你的流程。每个 RPA 实施之前都应该进行流程清单、动作分析、以及成本/价值的绘制练习。

这些练习对于理解流程中何处产生价值（或成本，如果没有价值的情况下）是至关重要的。并且这些练习需要在每个流程或者每个任务这样的粒度级别上来做。

这将有助你去识别和优先考虑最合适的自动化候选者。由于能够或者可能需要自动化的任务数量较多，流程一般需要分段实施自动化，因此优先级很重要。

建议：设置一个小的工作团队，每个运营团队都参与其中。从每个运营团队中提名一个协调人 —— 一般是运营团队的领导或者团队管理者。在团队级别上组织一次研讨会，去构建流程清单、识别候选流程、以及推动购买。你的自动化合作伙伴很可能有“加速器” —— 调查问卷、计分卡等等 —— 这些将帮助你加速完成这项活动。

3. 为优先业务提供强有力的指导

实施自动化经常会涉及到在运营团队之间，基于业务价值对流程选择和自动化优先级上要达成共识（有时候是打破平衡）虽然团队的参与仍然是分析和实施的关键部分，但是领导仍然应该是最终的决策者。

建议：安排定期会议从工作团队中获取最新信息。除了像推动达成共识和购买之外，工作团队还应该在团队层面上去查看领导们关于 ROI、平台选择、以及自动化优先级上的指导性决定。

4. 应该推动 CIO 和 COO 的紧密合作

当运营团队和技术团队紧密合作时，自动化的实施将异常顺利。COO 需要去帮助推动与 CIO 团队的合作。

COO 和其他运营领导人的参与和监督对成功实施自动化是至关重要的。

建议：COO 和 CIO 团队应该与第三方的自动化合作伙伴共同设立一个联合工作组（一个“战场”）。对每个参与者的责任进行明确的界定并持续跟踪。理想情况下，COO 和 CIO 应该至少有一个投入到联合工作组中，至少在初始发布中应该是这样。

自动化可以为组织创造重要的价值。然而为了在自动化中获得最优的投资回报，CIO 们必须在“入坑”之前做好规划。

via: https://enterprisersproject.com/article/2017/11/how-improve-roi-automation-4-tips

作者：Rajesh Kamath 译者：qhwdw 校对：wxy

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

这幅妙绝的题图来自 Miquel Beltran

我的技术生涯，从两年前算起。开始是 QA 测试员，一年后就转入开发人员角色。没怎么努力，也没有投入过多的个人时间。

你可以从我为何从生物学转向技术和我学习 Android 的一年 这两篇文章中找到些只言片语。今天，我想谈谈是自己是如何开始担任 Android 开发人员这个角色、如何换公司以及作为 Android 工程师的一年所得所失。

我的第一个职位角色

我的第一个职位角色， Android 开发者，开始于一年前。我工作的这家公司，可以花一半的时间去尝试其它角色的工作，这给我从 QA 职位转到 Android 开发者职位创造了机会。

这一转变归功于我在晚上和周末投入学习 Android 的时间。我通过了 Android 基础纳米学位、Andriod 工程师纳米学位课程，也获得了 Google 开发者认证。这部分的详细故事在这儿。

两个月后，公司雇佣了另一位 QA，我转向全职工作。挑战从此开始！

比起给他们提供一台笔记本电脑和一个 git 账号来说，要把某人转变为胜任的开发角色，显然困难重重。在这里我解释一下我在那段时间遇到的一些障碍：

缺乏预期

我面临的第一个问题是不知道公司对我的期望。我认为他们希望我从第一天起就有交付物，虽然不会要求像那些经验丰富的同事一样，但也要完成一个小任务就交付。这种感觉让我压力山大。由于没有明确的目标，我一直认为自己不够好，而且是个伪劣的冒牌货。

缺乏指导

在公司里没有导师的概念，环境也不允许我们一起工作。我们很少结对编程，因为总是在赶项目进度，公司要求我们持续交付。幸运的是，我的同事都乐于助人！无论何时我卡住或需要帮助，他们总是陪我一起解决。

缺乏反馈

那段时间，我从来没有得到过任何的反馈。我做的好还是坏？我应该改进些什么？我不知道，因为我没有得到过任何人的评论。

缺乏学习氛围

我认为，为了保持常新，我们应该通过阅读博客文章、观看演讲、参加会议、尝试新事物等方式持续学习。该公司在工作时间并没有安排学习时间，不幸的是，其它开发人员告诉我这很常见。由于没有学习时间，所以我觉得没有资格花费哪怕十分钟的时间来阅读与工作相关且很有意思的博客文章。

问题不仅在于缺乏明确的学习时间津贴，而且当我明确要求时，被拒绝了。

当我完成突击任务时，发生了一个例子，我们已经完成了任务，因此我询问是否可以用剩下的时间来学习 Kotlin。这个请求被拒绝了。

另外的例子是我想参加一个 Android 相关的研讨会，然后被要求从带薪年假中抽出时间。

冒充者综合征

在这公司缺乏指导、缺乏反馈、缺乏学习氛围，使我的开发者职业生涯的前九个月更加煎熬。我有感觉到，我内心的冒充者综合征与日俱增。

一个例子就是拉取代码进行公开展示和代码审查。有是我会请同事私下检查我的代码，并不想被公开拉取，向任何人展示。

其他时候，当我做代码审查时，会花好几分钟盯着“批准”按纽犹豫不决，在担心审查通过的代码会被其他同事找出毛病。

当我在一些事上持反对意见时，由于缺乏相关知识，担心被坐冷板凳，从来没有大声说出来过。

某些时间我会请同事私下[...]检查我的代码，以避免被公开展示。

新的公司，新的挑战

后来，我手边有了个新的机会。感谢曾经和我共事的朋友，我被 Babbel 邀请去参加初级 Android 工程师职位的招聘流程。

我见到了他们的团队，同时自告奋勇的在他们办公室主持了一次本地会议。此事让我下定决心要申请这个职位。我喜欢公司的箴言：全民学习。其次，公司每个人都非常友善，在那儿工作看起来很愉快！但我没有马上申请，因为我认为自己不够好，所以为什么能申请呢？

还好我的朋友和搭档推动我这样做，他们给了我发送简历的力量和勇气。过后不久就进入了面试流程。这很简单：以很小的程序的形式来进行编码挑战，随后是和团队一起的技术面试，之后是和招聘经理间关于团队合作的面试。

招聘过程

我用周未的时间来完成编码挑战的项目，并在周一就立即发送过去。不久就受邀去当场面试。

技术面试是关于编程挑战本身，我们谈论了 Android 好的不好的地方、我为什么以这种方式实现这功能，以及如何改进等等。随后是招聘经理进行的一次简短的关于团队合作面试，也有涉及到编程挑战的事，我们谈到了我面临的挑战，我如何解决这些问题，等等。

最后，通过面试，得到 offer，我授受了!

我的 Android 工程师生涯的第一年，有九个月在一个公司，后面三个月在当前的公司。

学习环境

对我来说一个大的变化就是每两周会和工程经理进行面对面会谈。那样，我很清楚我们的目标和方向。

在需要如何改进、需要如何提供帮助及如何寻求帮助这些事情上，我们得到持续的反馈和想法。他们除了提供内部培训的的福利外，我还有每周学习时间的福利，可以学习任意想学的。到目前为止，我正利用这些时间来提高我的 Kotlin 和 RxJava 方面知识。

每日的大部分时间，我们也做结对编程。我的办公桌上总是备着纸和笔，以便记下想法。我旁边还配了第二把椅子，以方便同事就坐。:-)

但是，我仍然在与冒充者综合征斗争。

仍然有冒充者综合征

我仍然在斗争。例如，在做结对编程时，当我对某个话题不太清楚时，即使我的同事很有耐心的一遍一遍为我解释，但有时我仍然还是不知道。

两次三次后，压力就堵到胸口。为什么我还不知道？为什么就那么难理解？这种状态让我焦虑万分。

我意识到我需要承认我确实不懂某个特定的主题，但第一步是要知道有这么个概念！有时，仅仅需要的就是更多的时间、更多的练习，最终会“在大脑中完全演绎” :-)

例如，我常常为 Java 的接口类和抽象类所困扰，不管看了多少的例子，还是不能完全明白他们之间的区别。但一旦我使用后，即使还不能解释其工作原理，也知道了怎么使用以及什么时候使用。

自信

当前公司的学习氛围提升了我的自信心。即使我还在问很多问题，也开始如鱼得水了。

经验较少并不意味着您的意见将不会被重视。比如一个提出的解决方案似乎太复杂了，我会挑战自我以更清晰的方式来重写。此外，我提出了一套不同的体验和观点，目前，对公司的应用程序用户体验改进有着很大帮助。

提高

工程师的角色不仅仅是编码，而是广泛的技能。 我仍然处于旅程的起点，在掌握它的道路上，我想着重于以下几点：

• 交流：因为英文不是我的母语，所以有的时候我需要努力传达我的想法，这在我工作中是至关重要的。我可以通过写作，阅读和交谈来解决这个问题。
• 提有建设性的反馈意见：我想给同事有意义的反馈，这样我们一起共同发展。
• 为我的成就感到骄傲：我需要创建一个列表来跟踪各种成就，无论大小，或整体进步，所以当我挣扎时我可以回顾并感觉良好。
• 不要着迷于不知道的事情：当有很多新事物出现时很难做到都知道，所以只关注必须的，及手头项目需要的东西，这非常重要的。
• 多和同事分享知识：我是初级的并不意味着没有可以分享的！我需要持续分享我感兴趣的的文章及讨论话题。我知道同事们会感激我的。
• 耐心和持续学习：和现在一样的保持不断学习，但对自己要有更多耐心。
• 自我保健：随时注意休息，不要为难自己。 放松也富有成效。

via: https://proandroiddev.com/a-year-as-android-engineer-55e2a428dfc8

作者：Lara Martín 译者：runningwater 校对：wxy

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

尽管有包括 GDPR 在内的法规，数据隐私对于几乎所有的人来说都是很重要的事情。

今天（LCTT 译注：本文发表于 2018/1/28）是 数据隐私日 Data Privacy Day ，(在欧洲叫“ 数据保护日 Data Protection Day ”)，你可能会认为现在我们处于一个开源的世界中，所有的数据都应该是自由的，就像人们想的那样，但是现实并没那么简单。主要有两个原因：

1. 我们中的大多数（不仅仅是在开源中）认为至少有些关于我们自己的数据是不愿意分享出去的（我在之前发表的一篇文章中列举了一些例子3）
2. 我们很多人虽然在开源中工作，但事实上是为了一些商业公司或者其他一些组织工作，也是在合法的要求范围内分享数据。

所以实际上，数据隐私对于每个人来说是很重要的。

事实证明，在美国和欧洲之间，人们和政府认为让组织使用哪些数据的出发点是有些不同的。前者通常为商业实体（特别是愤世嫉俗的人们会指出是大型的商业实体）利用他们所收集到的关于我们的数据提供了更多的自由度。在欧洲，完全是另一观念，一直以来持有的多是有更多约束限制的观念，而且在 5 月 25 日，欧洲的观点可以说取得了胜利。

通用数据保护条例（GDPR）的影响

那是一个相当全面的声明，其实事实上这是 2016 年欧盟通过的一项称之为 通用数据保护条例 General Data Protection Regulation （GDPR）的立法的日期。数据通用保护条例在私人数据怎样才能被保存，如何才能被使用，谁能使用，能被持有多长时间这些方面设置了严格的规则。它描述了什么数据属于私人数据——而且涉及的条目范围非常广泛，从你的姓名、家庭住址到你的医疗记录以及接通你电脑的 IP 地址。

通用数据保护条例的重要之处是它并不仅仅适用于欧洲的公司，如果你是阿根廷人、日本人、美国人或者是俄罗斯的公司而且你正在收集涉及到欧盟居民的数据，你就要受到这个条例的约束管辖。

“哼！” 你可能会这样说 ^注1 ，“我的业务不在欧洲：他们能对我有啥约束？” 答案很简单：如果你想继续在欧盟做任何生意，你最好遵守，因为一旦你违反了通用数据保护条例的规则，你将会受到你的全球总收入百分之四的惩罚。是的，你没听错，是全球总收入，而不是仅仅在欧盟某一国家的的收入，也不只是净利润，而是全球总收入。这将会让你去叮嘱告知你的法律团队，他们就会知会你的整个团队，同时也会立即去指引你的 IT 团队，确保你的行为在相当短的时间内合规。

看上去这和非欧盟公民没有什么相关性，但其实不然，对大多数公司来说，对所有的他们的顾客、合作伙伴以及员工实行同样的数据保护措施是件既简单又有效的事情，而不是仅针对欧盟公民实施，这将会是一件很有利的事情。 ^注2

然而，数据通用保护条例不久将在全球实施并不意味着一切都会变的很美好 ^注3 ：事实并非如此，我们一直在丢弃关于我们自己的信息——而且允许公司去使用它。

有一句话是这么说的（尽管很争议）：“如果你没有在付费，那么你就是产品。”这句话的意思就是如果你没有为某一项服务付费，那么其他的人就在付费使用你的数据。你有付费使用 Facebook、推特、谷歌邮箱？你觉得他们是如何赚钱的？大部分是通过广告，一些人会争论那是他们向你提供的一项服务而已，但事实上是他们在利用你的数据从广告商里获取收益。你不是一个真正的广告的顾客——只有当你从看了广告后买了他们的商品之后你才变成了他们的顾客，但直到这个发生之前，都是广告平台和广告商的关系。

有些服务是允许你通过付费来消除广告的（流媒体音乐平台声破天就是这样的），但从另一方面来讲，即使你认为付费的服务也可以启用广告（例如，亚马逊正在努力让 Alexa 发广告），除非我们想要开始为这些所有的免费服务付费，我们需要清楚我们所放弃的，而且在我们暴露的和不想暴露的之间做一些选择。

谁是顾客？

关于数据的另一个问题一直在困扰着我们，它是产生的数据量的直接结果。有许多组织一直在产生巨量的数据，包括公共的组织比如大学、医院或者是政府部门 ^注4 ——而且他们没有能力去储存这些数据。如果这些数据没有长久的价值也就没什么要紧的，但事实正好相反，随着处理大数据的工具正在开发中，而且这些组织也认识到他们现在以及在不久的将来将能够去挖掘这些数据。

然而他们面临的是，随着数据的增长和存储量无法跟上该怎么办。幸运的是——而且我是带有讽刺意味的使用了这个词 ^注5 ，大公司正在介入去帮助他们。“把你们的数据给我们，”他们说，“我们将免费保存。我们甚至让你随时能够使用你所收集到的数据！”这听起来很棒，是吗？这是大公司 ^注6 的一个极具代表性的例子，站在慈善的立场上帮助公共组织管理他们收集到的关于我们的数据。

不幸的是，慈善不是唯一的理由。他们是附有条件的：作为同意保存数据的交换条件，这些公司得到了将数据访问权限出售给第三方的权利。你认为公共组织，或者是被收集数据的人在数据被出售使用权使给第三方，以及在他们如何使用上能有发言权吗？我将把这个问题当做一个练习留给读者去思考。 ^注7

开放和积极

然而并不只有坏消息。政府中有一项在逐渐发展起来的“开放数据”运动鼓励各个部门免费开放大量他们的数据给公众或者其他组织。在某些情况下，这是专门立法的。许多志愿组织——尤其是那些接受公共资金的——正在开始这样做。甚至商业组织也有感兴趣的苗头。而且，有一些技术已经可行了，例如围绕不同的隐私和多方计算上，正在允许跨越多个数据集挖掘数据，而不用太多披露个人的信息——这个计算问题从未如现在比你想象的更容易。

这些对我们来说意味着什么呢？我之前在网站 Opensource.com 上写过关于开源的共享福利，而且我越来越相信我们需要把我们的视野从软件拓展到其他区域：硬件、组织，和这次讨论有关的，数据。让我们假设一下你是 A 公司要提向另一家公司客户 B ^注8 提供一项服务 。在此有四种不同类型的数据：

1. 数据完全开放：对 A 和 B 都是可得到的，世界上任何人都可以得到
2. 数据是已知的、共享的，和机密的：A 和 B 可得到，但其他人不能得到
3. 数据是公司级别上保密的：A 公司可以得到，但 B 顾客不能
4. 数据是顾客级别保密的：B 顾客可以得到，但 A 公司不能

首先，也许我们对数据应该更开放些，将数据默认放到选项 1 中。如果那些数据对所有人开放——在无人驾驶、语音识别，矿藏以及人口数据统计会有相当大的作用的。 ^注9 如果我们能够找到方法将数据放到选项 2、3 和 4 中，不是很好吗？——或者至少它们中的一些——在选项 1 中是可以实现的，同时仍将细节保密？这就是研究这些新技术的希望。 然而有很长的路要走，所以不要太兴奋，同时，开始考虑将你的的一些数据默认开放。

一些具体的措施

我们如何处理数据的隐私和开放？下面是我想到的一些具体的措施：欢迎大家评论做出更多的贡献。

• 检查你的组织是否正在认真严格的执行通用数据保护条例。如果没有，去推动实施它。
• 要默认加密敏感数据（或者适当的时候用散列算法），当不再需要的时候及时删掉——除非数据正在被处理使用，否则没有任何借口让数据清晰可见。
• 当你注册了一个服务的时候考虑一下你公开了什么信息，特别是社交媒体类的。
• 和你的非技术朋友讨论这个话题。
• 教育你的孩子、你朋友的孩子以及他们的朋友。然而最好是去他们的学校和他们的老师谈谈在他们的学校中展示。
• 鼓励你所服务和志愿贡献的组织，或者和他们沟通一些推动数据的默认开放。不是去思考为什么我要使数据开放，而是从我为什么不让数据开放开始。
• 尝试去访问一些开源数据。挖掘使用它、开发应用来使用它，进行数据分析，画漂亮的图， ^注10 制作有趣的音乐，考虑使用它来做些事。告诉组织去使用它们，感谢它们，而且鼓励他们去做更多。

注：

1. 我承认你可能尽管不会。
2. 假设你坚信你的个人数据应该被保护。
3. 如果你在思考“极好的”的寓意，在这点上你并不孤独。
4. 事实上这些机构能够有多开放取决于你所居住的地方。
5. 假设我是英国人，那是非常非常大的剂量。
6. 他们可能是巨大的公司：没有其他人能够负担得起这么大的存储和基础架构来使数据保持可用。
7. 不，答案是“不”。
8. 尽管这个例子也同样适用于个人。看看：A 可能是 Alice，B 可能是 BOb……
9. 并不是说我们应该暴露个人的数据或者是这样的数据应该被保密，当然——不是那类的数据。
10. 我的一个朋友当她接孩子放学的时候总是下雨，所以为了避免确认失误，她在整个学年都访问天气信息并制作了图表分享到社交媒体上。

via: https://opensource.com/article/18/1/being-open-about-data-privacy

作者：Mike Bursell 译者：FelixYFZ 校对：wxy

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

自动化专家分享了一点对 自动化不远的将来的看法。请将这些保留在你的视线之内。

我们最近讨论了 推动 IT 自动化的因素，可以看到当前趋势正在增长，以及那些给刚开始使用自动化部分流程的组织的 有用的技巧 。

噢，我们也分享了如何在贵公司进行自动化的案例及 长期成功的关键的专家建议。

现在，只有一个问题：自动化的下一步是什么? 我们邀请一系列专家分享一下 自动化不远的将来的看法。 以下是他们建议 IT 领域领导需密切关注的六大趋势。

1、 机器学习的成熟

对于关于 机器学习（与“自我学习系统”相似的定义）的讨论，对于绝大多数组织的项目来说，实际执行起来它仍然为时过早。但预计这将发生变化，机器学习将在下一次 IT 自动化浪潮中将扮演着至关重要的角色。

Advanced Systems Concepts, Inc. 公司的工程总监 Mehul Amin 指出机器学习是 IT 自动化下一个关键增长领域之一。

“随着数据化的发展，自动化软件理应可以自我决策，否则这就是开发人员的责任了”，Amin 说。 “例如，开发者构建了需要执行的内容，但通过使用来自系统内部分析的软件，可以确定执行该流程的最佳系统。”

假设将这个系统延伸到其他地方中。Amin 指出，机器学习可以使自动化系统在必要的时候提供额外的资源，以需要满足时间线或 SLA，同样在不需要资源以及其他的可能性的时候退出。

显然不只有 Amin 一个人这样认为。

“IT 自动化正在走向自我学习的方向” ，Sungard Availability Services 公司首席架构师 Kiran Chitturi 表示，“系统将会能测试和监控自己，加强业务流程和软件交付能力。”

Chitturi 指出自动化测试就是个例子。脚本测试已经被广泛采用，但很快这些自动化测试流程将会更容易学习，更快发展，例如开发出新的代码或将更为广泛地影响生产环境。

2、 人工智能催生的自动化

上述原则同样适合与相关的（但是独立的） 人工智能的领域。根据对人工智能的定义，机器学习在短时间内可能会对 IT 领域产生巨大的影响（并且我们可能会看到这两个领域的许多重叠的定义和理解）。假定新兴的人工智能技术将也会产生新的自动化机会。

SolarWinds 公司技术负责人 Patrick Hubbard 说，“人工智能和机器学习的整合普遍被认为对未来几年的商业成功起至关重要的作用。”

3、 这并不意味着不再需要人力

让我们试着安慰一下那些不知所措的人：前两种趋势并不一定意味着我们将失去工作。

这很可能意味着各种角色的改变，以及全新角色的创造。

但是在可预见的将来，至少，你不必需要对机器人鞠躬。

“一台机器只能运行在给定的环境变量中——它不能选择包含新的变量，在今天只有人类可以这样做，” Hubbard 解释说。“但是，对于 IT 专业人员来说，这将需要培养 AI 和自动化技能，如对程序设计、编程、管理人工智能和机器学习功能算法的基本理解，以及用强大的安全状态面对更复杂的网络攻击。”

Hubbard 分享一些新的工具或功能例子，例如支持人工智能的安全软件或机器学习的应用程序，这些应用程序可以远程发现石油管道中的维护需求。两者都可以提高效益和效果，自然不会代替需要信息安全或管道维护的人员。

“许多新功能仍需要人工监控，”Hubbard 说。“例如，为了让机器确定一些‘预测’是否可能成为‘规律’，人为的管理是必要的。”

即使你把机器学习和 AI 先放在一边，看待一般的 IT 自动化，同样原理也是成立的，尤其是在软件开发生命周期中。

Juniper Networks 公司自动化首席架构师 Matthew Oswalt ，指出 IT 自动化增长的根本原因是它通过减少操作基础设施所需的人工工作量来创造直接价值。

在代码上，操作工程师可以使用事件驱动的自动化提前定义他们的工作流程，而不是在凌晨 3 点来应对基础设施的问题。

“它也将操作工作流程作为代码而不再是容易过时的文档或系统知识阶段，”Oswalt 解释说。“操作人员仍然需要在[自动化]工具响应事件方面后发挥积极作用。采用自动化的下一个阶段是建立一个能够跨 IT 频谱识别发生的有趣事件的系统，并以自主方式进行响应。在代码上，操作工程师可以使用事件驱动的自动化提前定义他们的工作流程，而不是在凌晨 3 点来应对基础设施的问题。他们可以依靠这个系统在任何时候以同样的方式作出回应。”

4、 对自动化的焦虑将会减少

SolarWinds 公司的 Hubbard 指出，“自动化”一词本身就产生大量的不确定性和担忧，不仅仅是在 IT 领域，而且是跨专业领域，他说这种担忧是合理的。但一些随之而来的担忧可能被夸大了，甚至与科技产业本身共存。现实可能实际上是这方面的镇静力：当自动化的实际实施和实践帮助人们认识到这个列表中的第 3 项时，我们将看到第 4 项的出现。

“今年我们可能会看到对自动化焦虑的减少，更多的组织开始接受人工智能和机器学习作为增加现有人力资源的一种方式，”Hubbard 说。“自动化历史上为更多的工作创造了空间，通过降低成本和时间来完成较小任务，并将劳动力重新集中到无法自动化并需要人力的事情上。人工智能和机器学习也是如此。”

自动化还将减少令 IT 领导者神经紧张的一些焦虑：安全。正如红帽公司首席架构师 Matt Smith 最近指出的那样，自动化将越来越多地帮助 IT 部门降低与维护任务相关的安全风险。

他的建议是：“首先在维护活动期间记录和自动化 IT 资产之间的交互。通过依靠自动化，您不仅可以消除之前需要大量手动操作和手术技巧的任务，还可以降低人为错误的风险，并展示当您的 IT 组织采纳变更和新工作方法时可能发生的情况。最终，这将迅速减少对应用安全补丁的抵制。而且它还可以帮助您的企业在下一次重大安全事件中摆脱头条新闻。”

* 阅读全文: [12个企业安全坏习惯要打破。 ] *

5、 脚本和自动化工具将持续发展

许多组织看到了增加自动化的第一步，通常以脚本或自动化工具（有时称为配置管理工具）的形式作为“早期”工作。

但是随着各种自动化技术的使用，对这些工具的观点也在不断发展。

DataVision 首席运营官 Mark Abolafia 表示：“数据中心环境中存在很多重复性过程，容易出现人为错误，Ansible 等技术有助于缓解这些问题。“通过 Ansible ，人们可以为一组操作编写特定的步骤，并输入不同的变量，例如地址等，使过去长时间的过程链实现自动化，而这些过程以前都需要人为触摸和更长的交付时间。”

想了解更多关于 Ansible 这个方面的知识吗？阅读相关文章：[使用 Ansible 时的成功秘诀。 ]

另一个因素是：工具本身将继续变得更先进。

“使用先进的 IT 自动化工具，开发人员将能够在更短的时间内构建和自动化工作流程，减少易出错的编码，” ASCI 公司的 Amin 说。“这些工具包括预先构建的、预先测试过的拖放式集成，API 作业，丰富的变量使用，参考功能和对象修订历史记录。”

6、 自动化开创了新的指标机会

正如我们在此前所说的那样，IT 自动化不是万能的。它不会修复被破坏的流程，或者以其他方式为您的组织提供全面的灵丹妙药。这也是持续不断的：自动化并不排除衡量性能的必要性。

参见我们的相关文章 [DevOps 指标：你在衡量什么重要吗？ ]

实际上，自动化应该打开了新的机会。

Janeiro Digital 公司架构师总裁 Josh Collins 说，“随着越来越多的开发活动 —— 源代码管理、DevOps 管道、工作项目跟踪等转向 API 驱动的平台，将这些原始数据拼接在一起以描绘组织效率提升的机会和图景”。

Collins 认为这是一种可能的新型“开发组织度量指标”。但不要误认为这意味着机器和算法可以突然预测 IT 所做的一切。

“无论是衡量个人资源还是整体团队，这些指标都可以很强大 —— 但应该用大量的背景来衡量。”Collins 说，“将这些数据用于高层次趋势并确认定性观察 —— 而不是临床评级你的团队。”

想要更多这样知识， IT 领导者？注册我们的每周电子邮件通讯。

via: https://enterprisersproject.com/article/2018/3/what-s-next-it-automation-6-trends-watch

作者：Kevin Casey 译者：MZqk 校对：wxy

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

开源游戏开发插件运行虚幻引擎的用户使用基于 Web 的编程方式创建独特的用户界面元素。

游戏开发引擎在过去几年中变得越来越易于​​使用。像 Unity 这样一直免费使用的引擎，以及最近从基于订阅的服务切换到免费服务的 虚幻引擎 Unreal Engine ，允许独立开发者使用 AAA 发行商相同达到行业标准的工具。虽然这些引擎都不是开源的，但每个引擎都能够促进其周围的开源生态系统的发展。

这些引擎中可以包含插件以允许开发人员通过添加特定程序来增强引擎的基本功能。这些程序的范围可以从简单的资源包到更复杂的事物，如人工智能 （AI） 集成。这些插件来自不同的创作者。有些是由引擎开发工作室和有些是个人提供的。后者中的很多是开源插件。

什么是 BLUI？

作为独立游戏开发工作室的一员，我体验到了在专有游戏引擎上使用开源插件的好处。Aaron Shea 开发的一个开源插件 BLUI 对我们团队的开发过程起到了重要作用。它允许我们使用基于 Web 的编程（如 HTML/CSS 和 JavaScript）创建用户界面 （UI） 组件。尽管 虚幻引擎 Unreal Engine （我们选择的引擎）有一个实现了类似目的的内置 UI 编辑器，我们也选择使用这个开源插件。我们选择使用开源替代品有三个主要原因：它们的可访问性、易于实现以及伴随的开源程序活跃的、支持性好的在线社区。

在虚幻引擎的最早版本中，我们在游戏中创建 UI 的唯一方法是通过引擎的原生 UI 集成，使用 Autodesk 的 Scaleform 程序，或通过在虚幻社区中传播的一些选定的基于订阅的虚幻引擎集成。在这些情况下，这些解决方案要么不能为独立开发者提供有竞争力的 UI 解决方案，对于小型团队来说太昂贵，要么只能为大型团队和 AAA 开发者提供。

在商业产品和虚幻引擎的原生整合失败后，我们向独立社区寻求解决方案。我们在那里发现了 BLUI。它不仅与虚幻引擎无缝集成，而且还保持了一个强大且活跃的社区，经常推出更新并确保独立开发人员可以轻松访问文档。BLUI 使开发人员能够将 HTML 文件导入虚幻引擎，并在程序内部对其进行编程。这使得通过 web 语言创建的 UI 能够集成到游戏的代码、资源和其他元素中，并拥有所有 HTML、CSS、Javascript 和其他网络语言的能力。它还为开源 Chromium Embedded Framework 提供全面支持。

安装和使用 BLUI

使用 BLUI 的基本过程包括首先通过 HTML 创建 UI。开发人员可以使用任何工具来实现此目的，包括 自举 bootstrapped JavaScript 代码、外部 API 或任何数据库代码。一旦这个 HTML 页面完成，你可以像安装任何虚幻引擎插件那样安装它，并加载或创建一个项目。项目加载后，你可以将 BLUI 函数放在虚幻引擎 UI 图纸中的任何位置，或者通过 C++ 进行硬编码。开发人员可以通过其 HTML 页面调用函数，或使用 BLUI 的内部函数轻松更改变量。

将 BLUI 集成到虚幻 4 图纸中。

在我们当前的项目中，我们使用 BLUI 将 UI 元素与游戏中的音轨同步，为游戏机制的节奏方面提供视觉反馈。将定制引擎编程与 BLUI 插件集成很容易。

使用 BLUI 将 UI 元素与音轨同步。

通过 BLUI GitHub 页面上的文档，将 BLUI 集成到虚幻 4 中是一个轻松的过程。还有一个由支持虚幻引擎开发人员组成的论坛，他们乐于询问和回答关于插件以及实现该工具时出现的任何问题。

开源优势

开源插件可以在专有游戏引擎的范围内扩展创意。他们继续降低进入游戏开发的障碍，并且可以产生前所未有的游戏内的机制和资源。随着对专有游戏开发引擎的访问持续增长，开源插件社区将变得更加重要。不断增长的创造力必将超过专有软件，开源代码将会填补这些空白，并促进开发真正独特的游戏。而这种新颖性正是让独立游戏如此美好的原因！

via: https://opensource.com/article/18/6/blui-game-development-plugin

作者：Uwana lkaiddi 选题：lujun9972 译者：geekpi 校对：wxy

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