devops

1月15日，国内知名“精益产品开发”研究和实践者、阿里云云效资深技术专家何勉在阿里云《云计算情报局》线上直播栏目中，分享其对研发新模式的最新思考，提出“下一代精益开发方法”，助力企业在研发效能上提升10倍。 同时，他认为，云原生是效能提升的巨大契机，赋予了精益实践天然的优势，是精益实践的最佳助力。 下一代精益开发方法 作为《精益产品开发：原则、方法与实施》的作者，何勉专注于精益产品交付、精益创业、创新及精益产品设计。 在此次直播中，何勉提出了下一代精益开发方法(Advanced Lean Product Development)，简称 ALPD。这是何勉对“精益”再一次思考，也是在实践中对“精益”理论的提炼和总结。 精益思想的核心是:“最小化浪费、最大化价值和持续改善”，它与研发效能改进的的目标——持续地顺畅高质量交付有效价值——高度一致，催生了产品开发领域一系列革命性的方法，如:精益看板方法，精益需求，精益创业等。 然而，这些方法相对独立，没能为提升研发效能提供系统的方法体系，更缺少有效的落地解决方案。这正是 ALPD(下一代精益产品开发)要解决的问题，它以系统解决研发效能问题为牵引，构建了系统的方法体系和完整的解决方案。 具体什么是下一代精益开发方法？ 何勉认为，提升研发效能，就是要解决三个问题：局部效率不等于高效交付、高效交付不等于持续高效、高效交付不等于业务成功，进而实现

简介： 1月15日，国内知名“精益产品开发”研究和实践者、阿里云云效资深技术专家何勉在阿里云《云计算情报局》线上直播栏目中，分享其对研发新模式的最新思考，提出“下一代精益开发方法”，助力企业在研发效能上提升10倍。 同时，他认为，云原生是效能提升的巨大契机，赋予了精益实践天然的优势，是精益实践的最佳助力。 下一代精益开发方法 作为《精益产品开发：原则、方法与实施》的作者，何勉专注于精益产品交付、精益创业、创新及精益产品设计。 在此次直播中，何勉提出了下一代精益开发方法(Advanced Lean Product Development)，简称 ALPD。这是何勉对“精益”再一次思考，也是在实践中对“精益”理论的提炼和总结。 精益思想的核心是:“最小化浪费、最大化价值和持续改善”，它与研发效能改进的的目标——持续地顺畅高质量交付有效价值——高度一致，催生了产品开发领域一系列革命性的方法，如:精益看板方法，精益需求，精益创业等。 然而，这些方法相对独立，没能为提升研发效能提供系统的方法体系，更缺少有效的落地解决方案。这正是 ALPD(下一代精益产品开发)要解决的问题，它以系统解决研发效能问题为牵引，构建了系统的方法体系和完整的解决方案。 具体什么是下一代精益开发方法？ 何勉认为，提升研发效能，就是要解决三个问题：局部效率不等于高效交付、高效交付不等于持续高效、高效交付不等于业务成功

转载本文需注明出处：微信公众号EAWorld，违者必究。 恍惚间，DevOps已经被讨论十年了 “如果系统是集中式的、环境是同质化的，从开发环境向生产环境推送程序变化的过程非常简单，不需要太多的自动化；但是今天的应用需要7×24小时运行、采用分布式架构、部署到多种环境，变更过程变得愈加复杂、难以自动化……不论在大型组织还是小型组织，施行DevOps在技术上都非常具有挑战性。” 上面这段文字如果放在今天，那只是段关于DevOps的、稀松平常的讨论，但是如果它写于十年前，各位读者会不会感到有一些惊讶？ 这段文字写于2007年8月的下旬，很快就距今整十年了，这是我所知道的业内最早的关于DevOps的系统性讨论，我在整理收藏夹的时候偶然发现了它，这让我突然意识到： DevOps已经十年了。 可是，为什么雷声大雨点小？ 博客网站dev2ops.org（据说是devops.org被抢注了，所以他们只能加个2，而devops.org至今仍是个空域名）的文章“What makes dev2ops so hard anyway?” 文中还罗列了阻碍DevOps施行的几个因素： 变更结果的可靠性和可预见性 不同类型的变更（数据、代码、配置、内容、平台等）对系统造成的不同影响未被充分评估 对分布式系统各部分的变更非常难以协调 开发与运维的组织边界难以界定 这几个因素在今天依然阻碍着DevOps的施行

基础设施即代码正蓬勃发展。Palo Alto Networks Prisma cloud高级副总裁Varun Badhwar表示，它正在成为云安全的三大支柱之一，将DevOps和安全性结合在一起，共同推动DevSecOps市场。 基础设施即代码也是DevOps左移趋势的主要组成部分。Badhwar说：“左移安全现在意味着应用程序安全，这意味着软件组成分析，意味着基础设施即代码扫描——所有这些现在都可以由DevOps团队在管道中完成。” “目标是为DevOps团队正在使用的工具制定一套策略”，然而，虽然基础设施即代码应该越来越多地在DevSecOps世界中占据一席之地，但要使其以最佳方式满足组织的安全需求，仍然存在挑战。 Badhwar说：“在我与成百上千的客户的交流后，我认为安全团队仍在研究如何与DevOps团队合作，有效沟通，并全面共享一个通用的工具集。问题是infosec团队使用的大多数工具都是以运行时为中心的。它们并不是真正专门为基础架构即代码带来的范式转变而构建的。” 以前，DevOps中的安全性主要与部署有关，当时“我们生活在一个很多软件产品和应用程序都以每年或半年为发布周期的世界”。 “我认为很明显，企业需要更敏捷，更快地行动。这其中很多都是关于如何开发和部署实践，并使它们更加精简和迭代。如果你现在看，它已经从非常以部署和开发为中心，转变为我所说的全周期和全栈

小伙伴们大家好，这怎么又是周末了。时间过得真的是贼快了，本肥羊也快被岁月的杀猪刀宰割得不成羊样了... 今天不更新技术文，今天聊一下后面一段时间几个比较重要的内容上的 想法 和 安排 吧，小伙伴们也可以帮忙把把关。毕竟有些问题总有小伙伴们频繁的提起，我也坐不住，我也不太好意思了。 一直以来，总源源不断有小伙伴们咨询一些关于各个典型方向的 学习路线和规划安排 的相关问题。 诚然，一年多来，不管是通过文章还是视频，和非常多的小伙伴们交流，我发现一个最普遍的问题是，其实大家在技术学习的过程中，痛点往往不在于说具体某一项技术该怎么学，这个绝对不是最痛点。痛点往往在于很多小伙伴对于其想学的某个技术栈，或者技术方向，并没有一个宏观上的感性认知。从反馈来看，很多小伙伴疑惑当下一些主流岗位（或方向）的技术学习路线和具体规划。 作为一个纯靠自学的野党，我太理解小伙伴们需要方向和路线的心情，这简直就和我当年一毛一样的感受。 身处其中而不知所向 ，我真心觉得这是学习道路上最大的恶意。 大家知道，我自己以前是做通信业务相关的开发，C/C++开发相关方向接触得多一些，两年前又头铁转到了互联网Java后端，所以对于这两个我稍微了解一点的方向，大致倒还能叨一叨，所以之前就花过不少时间已经梳理了一下这两个方向的详细学习路线和规划： Java后端开发学习路线和规划 C/C++开发学习路线和规划（偏后台方向）

点击关注“ 有赞coder ” 获取更多技术干货哦～ 作者：费解 团队：效能改进 背景 众所周知，在丰田精益生产中，核心观念包含对人的尊重、消除浪费、持续改善，只有这样，企业才能保持良性运转，竞争力才会提升。而具体的浪费场景，被总结为「制造过剩、等待、搬运、库存、加工、额外动作、次品」七种，后来又增加了「管理」的浪费。 笔者所在效能改进团队，一直致力于精益的实践，从降本增效的角度，来提升有赞软件研发的效能，以应对这个充满不确定性时代的变化的冲击。而彼时的软件研发，从过程管理的角度，已将「项目制」普及到团队之中并持续发挥作用，但从工程实践的角度，虽然各部门都有一些基础设施，但仅为本部门服务，整体处于萌芽阶段，需要有一条主线将各独立的孤岛串接起来，发挥协同的价值。 一、工程实践的现状 1.1 技术债 有赞作为一家初创公司，首要任务是在市场竞争中活下来，所以在技术沉淀方面，于某段时期内处于被动局面，由业务裹挟着往前狂奔，是可以理解的，而且是必须经历的。但可以预见的是，长此以往，就会积累大量的技术债，而且会随着系统复杂度的上升，技术债所带来的研发成本会快速增加，直到它变成一堆无人敢碰的遗留功能。 从精益浪费的视角看，处理技术债就是一种「额外动作」，它是每次研发中一项绕不开的工作，但除了耗费大量人力物力和时间之外，并不产生任何价值。我们亟需掌握目前有多少技术债、风险如何、处理成本如何

什么是devops？随着时间的推移，devops的定义也在不断的演进。对于其定义可能出现千人千面，但从核心观点，整体业界还是保持着一致的认识。DevOps不是单一的技术或者工具，甚至不只是一个流程，他包含应用设计、敏捷开发、持续交付和监控运维等一系列流程，涉及到企业文化、团队协作流程等多个方面，它可以被理解为一系列可以高速、高质量进行软件开发的工具链。 结合软件生产全生命周期来看，devops落地实践的 核心目标是缩短开发周期，提高部署频率和更可靠的发布。 DevOps的诞生源于企业要适应这个瞬息万变的市场，能够做到持续交付。正如《持续交付2.0》作者在书中精炼的2个环：价值探索和快速验证。 快速验证环的 两个核心关键是质量与速度 它会要求以最可靠的质量和最快的速度，交付最小可行方案，可靠地收集真实反馈，来形成这样的闭环。对于质量来讲一个核心的实践就是质量内建，有一个公认的事实。那就是在整个持续交付全生命周期过程中，缺陷越滞后发现，所需要的成本就越高。质量内建就是要从生产过程中的第一个环节开始，就要注重产出物的质量，并且在每个环节中都要去开展质量保障活动，这就要求在软件全生命周期参与的各个角色都需要实时的对软件的质量负责。确保软件在交付到下一个环节前有了基础的质量保障。其核心目的就是减少因为质量问题导致的返工，避免浪费大量人力成本。 速度

微信公众号搜索 DevOps和k8s全栈技术 ，即可关注， 也可扫描文章最后的二维码关注公众号，每天会分享技术文章供大家参考阅读哈~ 配置一个Redis的exporter，我们通过redis进行暴露监控 我们在之前的Redis上添加 prometheus.io/scrape=true cat redis.yaml apiVersion : apps/v1 kind : Deployment metadata : name : redis namespace : kube-system spec : replicas : 1 selector : matchLabels : app : redis template : metadata : labels : app : redis spec : containers : - name: redis image : redis:4 resources : requests : cpu : 100m memory : 100Mi ports : - containerPort: 6379 - name: redis-exporter image : oliver006/redis_exporter:latest resources : requests : cpu : 100m memory : 100Mi ports : -

什么是手动测试？ 手动测试是其由QA分析师手动执行对软件的测试。执行此操作是为了发现正在开发的软件中的错误。 在手动测试中，测试人员将检查给定应用程序或软件的所有基本功能。在此过程中，软件测试人员无需任何自动化测试工具即可执行测试用例并生成测试报告。 它是所有测试类型的经典方法，可帮助发现软件系统中的错误。通常由经验丰富的测试人员执行，以完成软件测试过程。 什么是自动化测试？ 在软件自动化测试中，测试人员编写代码/测试脚本以自动执行测试。测试人员使用适当的自动化工具来开发测试脚本并验证软件。目标是在更短的时间内完成测试执行。 自动化测试完全依赖预先编写的测试脚本，该测试脚本会自动运行以将实际结果与预期结果进行比较。这有助于测试人员确定应用程序是否按预期执行。 自动化测试允许您执行重复性任务和回归测试，而无需人工测试人员的干预。即使所有过程都是自动执行的，自动化也需要一些人工来创建初始测试脚本。 手动测试和自动化测试之间的区别 参数 自动化测试 手动测试 定义 自动化测试使用自动化工具来执行测试用例。 在手动测试中，测试用例由人工测试人员和软件执行。 执行时间 自动测试比手动方法要快得多。 手动测试很耗时，并且占用人力资源。 探索性测试 动化不允许随机测试 手动测试中可以进行探索性测试 初始投资 自动化测试中的初始投资较高。尽管从长远来看投资回报率会更好。 手动测试的初始投资相对较低

简介： 在魔幻的2020年，从勒索病毒新面孔WannaRen火上热搜，到知名B站UP主被勒索后在线求助，可以看出勒索病毒依然是网络病毒中的“顶流”。 2020年，注定是要被历史铭记的一年，除了肆虐全球的新冠病毒，网络“疫情”也没有消停，各种新型勒索病毒不断涌现，黑客组织陆续壮大，甚至不少国外一些主流的勒索病毒运营团队在国内寻找勒索病毒分销运营商，通过暗网与国外运营商进行合作，进行勒索病毒的分发传播，谋取暴利。 一、2020年勒索病毒事件 在魔幻的2020年，从勒索病毒新面孔WannaRen火上热搜，到知名B站UP主被勒索后在线求助，可以看出勒索病毒依然是网络病毒中的“顶流”。下面我们来盘点部分2020年全球勒索病毒大事件。 3月，特斯拉、波音、洛克希德·马丁公司和SpaceX等行业巨头的精密零件供应商，总部位于科罗拉多州丹佛的Visser Precision遭受勒索软件DoppelPaymer攻击，黑客已经泄漏Visser Precision与特斯拉和SpaceX签署的保密协议。 4月，葡萄牙跨国能源公司（天然气和电力）EDP（Energias de Portugal）遭Ragnar Locker勒索软件攻击，10TB的敏感数据文件遭泄，赎金高达1090万美金。根据EDP加密系统上的赎金记录，攻击者能够窃取有关账单、合同、交易、客户和合作伙伴的机密信息。 6月