关于devops:什么是DevOps

原文链接:https://support.huaweicloud.com/reference-devcloud/devcloud_r... DevOps概述DevOps,即Development and Operations,是一组过程、办法与零碎的统称,用于促成软件开发、运维和品质保障部门之间的沟通、合作与整合。DevOps的呈现是因为软件行业日益清晰的意识到:为了按时交付软件产品和服务,开发和运维工作必须严密单干。DevOps可看作开发、运维和品质保障(QA)三者的交加。 DevOps静止源自于进步IT服务交付敏捷性的须要,晚期呈现在许多大型私有云服务提供商中,并被其认可。撑持DevOps的理念根底是麻利宣言,它强调人(和文化),致力于改善开发和运维团队之间的合作。从生命周期的角度来看,DevOps的实施者也试图更好的利用技术,尤其是自动化工具,来撑持越来越多的可编程的动静的基础设施。 DevOps的技术实际配置管理 软件配置管理的外围性能是版本控制。版本控制系统是一种软件,能够治理代码的所有版本并跟踪代码中的更改。 分布式Git VS 集中式SVN 版本控制系统分为集中式和分布式两种工作模式,Git和SVN是最为宽泛被应用的代表,Git因为其诸多特点,更适宜DevOps。 安全性——Git是分布式,而SVN是集中式,存在单点故障危险。分支性能——Git分支功能强大,便于查问和追溯分支间的提交历史,且反对双向合并。公布管制——Git公布管制相当灵便,而SVN并没有明确的公布管制配置。开发审核——Git反对团队成员自建分支和版本库,从提交阐明、代码标准等方面对提交逐个审核;而SVN则不具备这些性能。合并反对——Git基于DAG(有向非环图)的设计比SVN的线性提交提供更好的合并追踪,防止不必要的抵触,进步了工作效率。存储形式——Git把内容按元数据形式存储,而SVN是按文件。包文件 包文件通常不放在源码库中治理,而是应用专门的包文件仓库(repository)进行存储,并配合包文件依赖管理工具(Maven、npm、Ivy等)进行应用。包文件仓库能够大抵分为本地仓库、私服仓库、地方仓库三种。本地仓库是指开发者集体PC中包文件的存储;私服仓库通常是企业为了晋升包文件使用性能而搭建的局域网内共用的包文件仓库,通常应用开源的Nexus、artifactory等工具搭建;地方仓库是指开源包文件的共享社区。 开发人员对包文件的应用集中在下载、搜寻、公布上传几个操作上。开发和构建时,开发人员通过包依赖管理工具定义好须要应用的公有及开源包文件,在构建或运行时主动从私服仓库或开源地方仓库中下载依赖包文件来晋升开发效率。 继续集成(Continuous Integration) 继续集成(CI)是一种软件开发实际,即团队的成员常常集成他们的工作,通常每个成员每天至多集成一次——这导致每天产生屡次集成。每次集成都通过自动化的构建(包含测试)来验证,从而尽快的检测出集成谬误。 继续集成过程中的角色与职责如下: 角色职责开发人员1. 实现开发工作,并在向版本控制库提交代码之前,先在本地环境实现一次公有构建。批改反馈回来的代码问题,放弃集成构建的绿灯状态。 || 测试人员 | 依据我的项目停顿随时更新自动化测试脚本,并保障代码覆盖率达到团队要求。 || 运维人员 | 1. 依据开发人员的须要,及时更新保护自动化构建脚本。保护整个CI流水线的失常运行。 |继续交付(Continuous Delivery) 继续交付(CD)是从构建环境到生产环境的构建、测试、配置和部署的过程。 继续交付是一种软件工程手法,让软件产品的产出过程在一个短周期内实现,以保障软件能够稳固、继续的放弃在随时能够公布的情况。它的指标在于让软件的构建、测试与公布变得更快以及更频繁。这种形式能够缩小软件开发的老本与工夫,缩小危险。 基础设施即代码(Infrastructure as Code) 作为代码的基础设施(IaC)是描述性模型中的基础设施(网络、虚拟机、负载平衡器和连贯拓扑)的治理,应用与DevOps团队用于源代码雷同的版本。与同一源代码生成雷同二进制文件的准则一样,IaC模型在每次利用时都会生成雷同的环境。 IaC是DevOps的要害实际,与继续交付联合应用 。 施行IaC的团队能够疾速、大规模的提供稳固的环境。团队通过代码示意环境的冀望状态,从而防止手动配置环境并强制实现一致性。应用IaC进行基础架构部署是可反复的,可避免因配置偏差或短少依赖性而导致的运行时问题。DevOps团队能够与一组对立的实际和工具协同工作。疾速,牢靠,大规模的交付应用程序及其反对基础架构。 DevOps转型的研发工具链疾速交付的要害是“主动”与“牢靠”。主动是一个很宽泛的词汇,在软件交付中代表着测试自动化、交付自动化、运维自动化等,而牢靠讲的是每一次交付要保障是以后的交付是稳固的或可回滚到稳固版本的。 为了解决“主动”与“牢靠”的问题,麻利开发鼻祖Martin Fowler提出了继续集成与继续交付的概念,它所形容的软件开发,是从原始需要辨认到最终产品部署到生产环境这个过程中,需要以小批量模式在团队的各个角色间顺畅流动,可能以较短的周期实现需要的小粒度频繁交付。频繁的交付周期带来了更迅速的对软件的反馈,并且在这个过程中,需要剖析、产品的用户体验和交互设计、开发、测试、运维等角色密切协作,相比于传统的瀑布式软件团队,更少节约。通过这种小步快跑的形式,将小性能疾速迭代、验证、交付,通过自动化的工具,将测试、部署、运维自动化,缩小需要在软件生命周期中流动的工夫。 华为将本身积攒的先进研发能力与优良实际凋谢,交融麻利、精益、DevOps等先进研发理念,打造凋谢残缺的云端开发生态,推出了一站式、全流程、平安可信的DevOps云平台——CodeArts,详情请参见CodeArts产品概述。

February 22, 2024 · 1 min · jiezi

关于devops:DevOps|研发效能团队组织架构和能力建设-审核中

研发效力团队绝对于各个公司主营业务规模来说并不是很大,然而在经验的几家公司里次要是有两种组织架构,职能独立型组织架构和业务闭环型组织架构。本文次要解说这两种组织架构的特点、优劣、劣势。 业务闭环组织架构 这里引入了一个概念-个性团队,以及个性团队的负责人(FTO),更多的内容在我之前的文章《研发效力组织能力建设之个性团队FeatureTeam(上)》有过介绍,这里只把一些关键点列出来。个性团队是一个长期稳固、跨职能跨组件、继续端到端交付用户价值的团队。个性团队就是一个业务闭环的组织架构。图中的负责具体业务的运维人员、QA、设计师甚至都能够闭环到业务中去,这样整体效率会更高。 业务闭环组织架构特点最大化响应速度最大限度缩小内部、外部依赖最大限度升高沟通老本最大限度升高决策老本责、权、利对等业务闭环组织架构益处交付快,单位产出多小步快跑,唯快不破,精英小团队团队内能够做到端到端交付,极少等待时间,交付速度快一手的信息起源,从头跟到尾的负责制模式缩小团队之间依赖,打算更容易、更有保障如果团队间有依赖,那必定是弱依赖,如果是十分强的依赖,团队外部要么有人被动进去承当这部分工作,要么闭环到团队外部。团队外部疾速沟通、交换、决策,疾速响应用户的诉求大家都围绕着几个桌子坐,每日例会,平时有问题疾速沟通。以业务为核心、以用户为核心驱动团队运行闭环团队的工作人少活多,强调自我驱动、被动承当。责、权、利对等,成员责任心、自驱力高大家每天坐在一起工作,每天做什么,做得怎么样,团队贡献度,每个人心里都有一杆秤业务闭环组织架构劣势团队整体压力大对业务闭环组织的负责人(FTO)要求高,定方向、搭班子、带团队的综合能力都要很杰出。FTO岂但要强于业务,还要在多项职能上都要有很好的判断,尤其是率领产品、研发、QA、运维、设计师、经营等多种背景的小伙伴上。尽管很多决定是FTO和团队沟通后作出的,然而咱们仍然认为FTO是所有问题的第一责任人,团队外部所有问题,业务问题等都要FTO担责,FTO压力比职能型管理者大很多。千金易得,一将难求对成员要求高,一直学习、自我驱动、被动承当。每日例会,每个人都做了哪些事件品质如何,团队外部每个人心知肚明,大家都晓得。工作催的紧,工作压力很大,「葛优躺」「摸鱼族」难生存,未必所有人都能适应长期高强度的端到端用户价值的交付,团队注意力全副集中在事上,工作压力大、对团队外部成员的关心度低长时间工作在一个业务畛域,局部队员可能会对做的事件失去趣味,公司、部门须要有便当的外部活水、转岗制度和机制。很多公司在这一点做得不好,我感觉要放开这方面的限度。各个业务闭环团队都会针对本人的团队、本人的业务十分理论地做出决定,在技术栈抉择、规范性听从上个别不是很重视,须要技术委员会、专家团队横向疏导业务闭环组织架构的一个很重要的点在于找到一个懂业务的 FTO来负责整个业务。 职能独立型组织架构 职能独立型组织架构特点每个人都依据业余线,依照职能向上汇报,决策集中在最高领导当须要做我的项目时,从产品、技术,运维、QA等团队中抽调人员组成我的项目团队。一线的我的项目人员须要依照职能线向上汇报,也须要横向做我的项目上的沟通,有更多的沟通、协调工作。对一线的我的项目人员要求高。岂但要解决好我的项目上的事件,还须要解决好职能线的事件。尽管某些公司号称context not control,然而理论一线的我的项目人员在某些方面还是无奈作出决策的,要一直的向上反馈,有时要回升到整个组织/团队的高层,同时也须要一直的横向沟通为了推动我的项目顺利开展,因为波及泛滥角色,须要更多工作流程、平台的反对,以便缩小在含糊地带、两头地带的沟通、期待、决策老本。我的项目规模大、共享资源多比拟适宜成熟的业务,或者团队比拟大的公司职能独立组织架构劣势专家领导专家。你的汇报线都是相干职能的专家。下级对上级有相对的业余判断。很少会呈现在行领导外行。同一职能团队外部能够互相交换、互相声援因为决策团队中蕴含了各个职能的相干人员,个体决策。个体决策在大团队大组织里永远是最不坏的抉择,但未必是最优抉择。面向规定办事,所有走流程职能独立组织架构劣势决策链路长、决策过程慢,决策工夫长职能线之间达成统一后,再横向沟通,横向都称心后我的项目能力向下推动。如果有不同意见,那么只能职能线沟通->横向沟通再来一遍。职能线外部也要同时承当多个横向我的项目,优先级重要度呈现变动时,其余职能团队也须要变动,但未必能及时反馈。责、权、利不对等。「摘桃子」「背黑锅」常产生。职能线外部被「摘桃子」「背黑锅」时常产生。不同职能线基于脸面都是有桃子一起吃,更多的是「被甩锅」。各个职能部门的利益与横向团队的利益、客户的需要未必统一,短少用户利益的代言人谁代表用户谁有决定权。职能独立型的组织之间,各个职能是互相配合的关系,谁都能够说代表用户可是谁又无奈齐全代表。宰割的各个职能部门之间的沟通交流合作耗时、耗力、费神依照流程做事,个体决策,各个职能部门个体对最终业务成绩负责,经常导致无人对业务后果负责谁都在做事,也都很辛苦,可是最初后果不好,能怪谁?产研运各个职能向上最近交叉点的那个人么?更多的对流程、对撑持平台的反馈、埋怨。然而平台无奈解决解决不了人心。本文总结本文次要比照了职能独立型组织架构和业务闭环型两种组织架构的特点、劣势、劣势。通常来说对于小组织、小业务、业务指标绝对明确采纳业务闭环型组织更好。 浏览我的更多文章研发效力组织能力建设之个性团队FeatureTeam(上)高效能麻利交付团队反思:个性团队(FeatureTeam)+Scrum互联网公司研发效力/工程效率团队建设和布局找到能做好研发效力的人中小互联网公司研发效力团队规模、职能划分和优劣势剖析

September 25, 2023 · 1 min · jiezi

关于devops:您距离一个成熟安全的-DevOps-平台只差一个迁移

历经 14 年的倒退后,DevOps 曾经不再是一个鲜为人知的术语,国内外泛滥企业在成熟方法论和简单工具链的加持下,通过 DevOps 的落地实际实现了软件交付效率的晋升。随着 DevOps 的深刻倒退,DevOps 的市场规模也在进一步疾速倒退。 依据 Research and Markets 的调研数据,2020 年寰球 DevOps 市场规模大概为 88.8 亿美金,2023 年增长至 108.4 亿美金,年复合增长率为 22.1%;而这一数据将在 2027 年将达到惊人的 247.1 亿美金,年复合增长率晋升至 22.9%。 如此大的市场也吸引了很多厂商在 DevOps 赛道进行布局,而且新的工具、产品正在源源不断涌现。寰球出名 IT 征询和钻研公司 Gartner 将这些厂商提供的工具或产品进行了划分,公布了业界出名的 DevOps 平台魔力象限。魔力象限分为四个象限:NICHE PLAYERS(利基)、VISIONARIES(有远见)、CHALLENGERS(挑战者) 以及 LEADERS(领导者)。其中 LEADERS 象限中的产品为最高级,意味着产品的能力和市场认可度都是很高的。而 GitLab 就位于 DevOps 平台魔力象限的领导者象限。 为了更好的服务中国用户,极狐GitLab 诞生了。作为 GitLab 在中国的发行版,极狐GitLab 作为一个成熟平安的 DevOps 平台,具备以下劣势: 功能丰富,开箱即用DevOps 自身就是心愿通过端到端的交付能力来帮忙企业减速从“想法”到部署上线的整个过程。而极狐GitLab 作为一个一体化的 DevOps 平台,提供笼罩软件研发全生命周期的 DevOps 能力,包含麻利项目管理、源代码托管、CI/CD、平安治理、监控运维等。所有性能开箱即用,无需装置运维第三方工具,为用户节约了多工具链的购买老本和运维老本。 平安保障,质效并行软件品质和交付效率是企业放弃竞争力的外围。极狐GitLab 一体化平台可能让所有与软件研发相干的人员(产品、研发、测试、平安等)都在同一个平台上进行合作,升高了沟通老本,晋升了研发效率。同时,内置的 JiHu Flow,将代码审核、平安扫描等嵌入研发工作流,保障了交付软件的品质。 此外,极狐GitLab 还提供性能齐备的软件研发平安防护体系。包含平台账号治理、仓库权限治理、代码分支治理、代码平安扫描、破绽平安治理等。多层级防护为软件研发构建了一个纵深进攻体系。尤其极狐GitLab 的七大平安扫描性能:密钥检测、依赖项扫描、SAST(包含 IaC 扫描)、DAST、容器镜像扫描、许可证合规、含糊测试(基于 API 和 Web 两种)。平安扫描内嵌至极狐GitLab CI,两行代码即可开启扫描,真正实现 DevSecOps 的“平安左移”。 ...

September 21, 2023 · 1 min · jiezi

关于devops:Appilot发布打造面向DevOps场景的开源AI助手

今日,数澈软件Seal (以下简称“Seal”)发表推出面向 DevOps 场景的 AI 助手 Appilot,这款产品将充分利用 AI 大语言模型的能力为用户提供变革性的部署和利用治理体验。Seal 此次公布的 Appilot 我的项目,能够让用户间接输出自然语言即可实现利用治理、环境治理、故障诊断、混合基础设施编排等性能。  “以后 AI 技术正以不可逆转的趋势渗透到 IT 行业的方方面面。” Seal 联结创始人及 CEO 秦小康示意:“今年以来,大概有十多家企业客户向咱们表白了他们对于 AI 的迫切需要——心愿借助 AI 的能力优化外部的 DevOps 流程。因而咱们推出 Appilot,来帮忙研发和运维团队更轻松地实现利用部署和治理。”  GitHub 地址:https://github.com/seal-io/appilot  开释 AI 之力,简化利用部署与治理随着企业技术架构的演进,DevOps 工作变得愈发简单和繁琐,施行和保护老本迅速攀升,开发和运维人员对此均苦不堪言。上个月,Seal 开源的利用部署治理平台 Walrus 通过拆散研发和运维的关注点、升高应用基础设施的复杂度,初步解决了这一问题。Appilot 的推出更是进一步简化利用部署与治理体验。    Appilot 基于大语言模型进行推理,并且能够运行在本地个人电脑上。用户能够依据本身的需要和应用习惯,将 Appilot 集成到任意平台,进而实现通过输出自然语言即可调用后端平台的能力。具体个性包含:  利用治理:借助 Appilot,您能够通过自然语言交互来轻松地部署、降级、回滚和查看应用程序的日志,无需繁琐的手动操作。环境治理:无论克隆环境还是查看环境内的依赖关系,均可通过 Appilot 实现,应用简略的指令即可实现简单的环境治理工作。诊断排障:如果发现零碎异样,Appilot 所领有的排查和修复性能,能够帮忙您疾速辨认问题并采取措施解决它们。行为护栏:咱们深知平安的重要性,因而 Appilot 仅提供畛域特定的答复,并要求审批任何可能导致系统变更的操作,有助于确保您的零碎不会受到未经受权的拜访。混合基础设施编排:Appilot 能够轻松对接任意基础设施,无缝集成各种云服务、容器化平台等,使您可能在多样化的环境中运行应用程序。反对多语言:您能够采纳包含但不限于中文、英文等语言输出指令进行交互。可插拔后端:咱们秉持着开源凋谢的理念,防止供应商锁定。因而您能够依据须要自定义后端,以满足您的具体需要。 齐全开源,欢送应用Seal 继续践行开源的理念和承诺。Appilot 我的项目基于 Apache 2.0 许可证开源,您能够通过拜访我的项目的 GitHub 地址下载和装置 Appilot,如果您喜爱这个我的项目,也欢送为咱们点赞~  GitHub 地址:https://github.com/seal-io/appilot 

September 20, 2023 · 1 min · jiezi

关于devops:研发效能|DevOps-是运维还是开发

DevOps 到底是 Dev还是Ops?答:属于研发工程师序列,偏差研发域,而不是运维域。 DevOps是研发工程师DevOps 次要服务的对象就是所有产研团队的人员,与产研团队打交道比拟多,相互配合更多,所以 DevOps 划分到 Dev 一侧比拟好。 Ops 更专一底层基础设施,IaaS,PaaS,和利用稳定性这些方面。 通常 DevOps 团队是负责开发产研基础设施的团队,反而外面很少有 Ops 工程师,基本上都是产品、开发和经营人员,咱们都是当作一个业务团队来运行。 我负责 DevOps 团队时,有些运维的小伙伴也想在工作之余退出进来做些开发的工作,这当然是欢送的。然而运维的小伙伴有很多本人本职的工作,过了一段时间咱们都发现了问题。 运维的小伙伴自身很忙,只有很少甚至没有工夫来写代码我的项目排期紧,运维小伙伴领了开发工作,然而太忙了,根本无法跟上我的项目开发进度。我的项目上的很多事件,都是有明确工夫点的,没按期交付整个团队都受影响。尝试了一两个迭代后,咱们就完结了这种做法。运维团队负责底层基础设施,咱们负责下面的平台建设。咱们做平台,他们用平台。 DevOps招聘误区DevOps 的次要工作在开发,而不是 Ops。很多公司招很多运维来做 DevOps 零碎,对于小公司兴许能够,然而略微大点的公司根本都不这么做。 招运维工程师来做 DevOps 个别都是小公司。你看我招了一个运维工程师还能做 DevOps 平台,两全其美,忙的时候做运维,闲的时候做运维自动化零碎,「可是占了大便宜」。这些做法在公司还小的时候无可非议,然而不能奉若至宝,认为这个情理放之四海哪里都能够跑得通。 其实对于小公司很少有资源真正投入到做 DevOps平台,也不须要开发工程师,个别都是配置管理工程师、QA、运维工程师一起配合就能搞定。只有公司体量起来了,须要自研了,才真正的须要 DevOps 工程师,但这时候更须要专职的研发工程师了,配置管理工程师和运维工程师也成了平台的业务方。 咱们招聘 DevOps 工程师的时候都是间接招聘开发工程师。这里要留神的一点就是并不是所有的开发工程师都违心做外部平台,做 DevOps 零碎,因为外部零碎的下限和业务研发比照太低了,提供的机会也少。这一点和国外很多公司有很大区别,招聘的时候肯定要讲明确。否则人来了两天就跑了,节约感情和精力。 运维平台建设运维小伙伴在大多数公司都是人力资源有余的状况,公司也违心把人力资源投入到业务,而不是撑持平台。运维小伙伴终日忙得脚都朝天了,其实即使主观能动上想去开发一些零碎,也是爱莫能助。我意识的很多运维小伙伴每天都要忙到中午,有时后半夜还要解决监控告警、导数据、迁机器。 运维团队须要研发的很多零碎谁来做呢?那些不间接面对用户、优先级不高的零碎能够让运维团队看本人工夫安顿自主抉择。其余零碎都是咱们团队在撑持。咱们建设平台、运维小伙伴用,正当分工,各自安好。 小公司招聘运维工程师做DevOps平台想法是好的,但往往也就是给运维换了个头衔而已;小公司的运维太忙,基本没工夫开发; 小公司也没资源投入到自研 DevOps 平台建设。少数状况下开源工具够用了(有点逼格的公司除外)。 本文小结本文次要讲了 DevOps 工程师次要的工作属于研发工程师序列,偏差研发域,而不是运维域。与此同时,招聘的时候也要招聘一些虚浮、靠谱、能力强的小伙伴。外部产研运合作平台不是久而久之就能做好的,须要长期、一直的投入,大处着眼,小处着手,一步步好高鹜远地往前走,最终守得云开见月明。 浏览我的更多文章 互联网公司研发效力/工程效率团队建设和布局 破局DevOps|8大北极星指标指引研发效力方向 DevOps | 产研协同效力晋升之评审、审批流、品质卡点 DevOps|研发效力+项目经理PMO devops|中小公司效率为王,没必要度量

September 18, 2023 · 1 min · jiezi

关于devops:为-DevOps-战士准备的-Linux-命令

点击链接理解详情 这篇文章将帮忙了解DevOps工程师所需的大部分重要且常常应用的Linux命令。 要执行这些命令,你能够应用任何Linux机器、虚拟机或在线Linux终端来迅速开始应用这些命令。 零碎信息命令: hostname - 显示零碎主机的名称。 hostid - 显示由操作系统调配的零碎主机ID。 date - 以UTC格局显示以后日期和工夫。 whoami - 显示终端以后登录的用户名。 uptime - 显示自机器登录以来通过的工夫。 uname - Unix名称。 clear - 清屏。 history - 列出到目前为止执行的所有命令。 sudo - 超级用户执行。 echo $? - 显示最初一个执行的命令的退出状态(0 - 胜利,1-255 - 谬误/失败)。 shutdown -r now - 立刻重启机器(-r 重启)。 printenv - 显示Linux零碎的所有环境变量。 last - 显示Linux零碎中之前的登录信息。 目录命令: pwd - 显示当前工作目录(缩写为Print Working Directory)。 cd - 更改目录。 cd .. - 更改到其父目录,即向上一级。 cd <dirName> - 更改到所提到的目录。 ...

September 11, 2023 · 4 min · jiezi

关于devops:DevSecOps-中的漏洞管理下

建设破绽管理程序以反对DevSecOps在探讨DevSecOps及DevOps模型中蕴含安全性的重要性时,建设无效的破绽治理实际是十分重要的。这能够通过将破绽治理设置为程序来实现。 咱们能够开始对IT组织进行破绽治理评估。人们常常问的问题可能是,既然曾经建设了一些补救机制,为什么还须要进行评估。但领有这些类型的评估以跟上平安和破绽修复的行业标准是极其重要的。以下就是须要进行破绽治理评估并跟上行业平安规范的起因之一。 在典型的IT组织中,咱们用于软件开发的我的项目中,只有20%-25%的自定义代码。咱们将应用所有工具进行不同类型的代码扫描,并确保修复破绽。然而,其余的代码将来自开源模块和库。咱们查看出的框架和库将继承上面的更多框架和库,咱们可能不晓得这些代码有多洁净。这些代码不是外部编写的,咱们不晓得它为胜利运行所做的一些调用;另一方面,咱们有蕴含包和元数据的容器。如果没有以正确的形式进行配置,作为代码的基础设施可能会为破绽开拓多种路径。 因而,正确施行DevSecOps能够首先缓解破绽,而正确的破绽治理能够补救凋谢的破绽。 通过破绽治理实际实现高效应用程序平安的步骤,直到操作成熟: 1.破绽治理评估评估对于理解IT组织的环境十分重要。这将使咱们可能优先思考防止危险的破绽类型——剖析破绽危险并关注紧急情况。咱们能够定义、辨认和监控已知或新呈现的破绽的端点。 2. 身份和拜访治理须要高效的IAM(Identity and Access Management,身份辨认与拜访治理)来被动避免破绽的关上。IAM是组织中须要搁置平安层时外部网络和内部网络之间的网关。利用适当的身份验证技术,如多因素身份验证(MFA,Multifactor Authentication)、Sigle Sign-On(SSO,Sigle Sign-On)和基于危险的身份验证(RBA,Risk-based authentication)。 IAM的劣势如下: 确保数据机密性数据安全阻止恶意软件攻打将组织门户仅限于所需的各方3.SAST 和 DAST扫描SAST:动态应用程序平安测试分析程序源代码,以辨认安全漏洞。SAST办法领导开发人员在晚期开发阶段开始测试他们的应用程序,而不执行性能组件。这种办法能够尽早发现应用程序源代码的平安缺点,防止将平安问题留给前期的开发阶段。这缩小了开发工夫并加强了整个程序的安全性。 DAST:动静应用程序平安测试实时扫描软件应用程序,查找次要破绽起源,发现安全漏洞或凋谢破绽。DAST测试正在运行的应用程序,但不能拜访其源代码。DAST是一种关闭盒测试模式,能够刺激内部攻击者的视角。它假如测试人员不晓得应用程序的外部性能。它能够检测SAST无奈检测的安全漏洞,例如仅在程序运行时呈现的破绽。 因为DAST测试须要一个残缺的工作应用程序,所以将它们保留到利用程序开发过程的前期阶段。测试人员须要与应用程序交互:提供输出、查看输入,并模仿用户交互的其余典型操作。 4. 无效配置管理数据库(CMDB,Configuration Management Database)放弃最新的配置管理数据库是胜利的破绽程序极为重要的方面。了解组织的软件资产和配置管理过程是要害。配置发现工具,以更通明地洞察软件配置。更新CMDB并将配置项映射到服务和应用程序。 论断在领有高节奏的开发环境和具备自动化管道的IT经营团队的组织中,实现无效的破绽治理十分重要。思考到目前的行业局势,预防安全漏洞和网络攻击如呼吸个别重要。这能够通过在软件开发生命周期的晚期和所有阶段引入平安方面并及时修复破绽来实现。

September 11, 2023 · 1 min · jiezi

关于devops:破局DevOps|8大北极星指标指引研发效能方向

放弃那些动辄就上百个的研发度量指标吧,8大北极星指标指引你的研发效力方向,1个北极星指标公式让你清晰理解公司研发效力现状。 每当研发效力/DevOps业务做布局的时候,有的人就会毫无脉络,不晓得如何下手,不晓得方向在哪里,价值怎么掂量。本文将介绍如何借助北极星指标这个工具来帮咱们实现这项工作,并以此指引团队工作方向,梳理业务重点,聚焦外围指标。这也是我罕用的办法,心愿对你有用。 研发效力北极星指标公式 先给出研发效力北极星指标公式,前面会详细分析、解说这个公式的由来和用法。 北极星指标北极星指标(North Star Metric),也叫作第一要害指标,是指在产品的以后阶段与业务/策略相干的相对外围指标,一旦确立就像北极星一样闪耀在地面,指引团队向同一个方向迈进。 北极星指标三个重要作用 指引将来:可能清晰地表明产品要传播的性能点和产品将来阶段须要优化的方向。指引产品倒退方向,所有需要开展的根底。团队协同:可能让其余产品组的共事晓得以后产品组的实时停顿,便于跨组的资源协同。能够帮忙咱们明确任务的优先级,很多小伙伴都说本人的工作优先级高,到底高不高,能够看下产品北极星指标。后果导向:可能使咱们对后果负责,即以业务成果/后果而不是业务数量来掂量团队的工作品质。有量化的指标才会让咱们不迷茫,有能源,有口头力,工作聚焦。北极星指标三个重要属性 明确掂量的指标体现产品价值与客户价值的指标营收先导指标(而不是滞后指标)指标制订个别要求合乎SMART准则,这里有个暗含的因素 T,能够依据OKR周期来确定。 北极星指标制订规范 体现产品的外围价值,即能够晓得用户是否体验到了产品要提供、传播的外围价值反映用户的沉闷水平,指标越高是否阐明用户沉闷水平更高反映产品的实时倒退,指标进步是否阐明产品在往好的方向倒退(警觉虚荣指标)将来营收的先导指标,即依据这一指标能够肯定水平预测将来的营收状况易于了解、明确掂量,即定义清晰,并且容易被所有人了解、交换、执行研发效力业务特点研发效力实质上属于企业中后盾业务。用户数量下限十分确定,根本不会超过企业人数,中后盾业务没有企业营收要求,基本上是老本核心,而不是利润核心。研发效力属于创造型、工具型的业务,绝对于电商型的淘宝京东和内容型的抖音快手。产研运团队每天都要在研发效力平台上实现工作,发明和交付用户价值。研发效力平台属于效率晋升工具,次要的指标是打造高度易用的平台,晋升用户高频操作的效率,造就用户应用习惯与粘性。研发效力北极星指标 周沉闷用户数占比:[周沉闷人数/指标用户人数],指标用户人数粗略可用公司总人数来计算,此指标反映业务规模。*平台SLA: [0.995 ~0.999],反映零碎稳定性*零碎NPS: [1~10分], 反映间接用户对研发效力业务的整体评估,个别以季度或者半年期数据为准*用户正反馈次数:[1~10次],每一个正反馈都是非常难得的认可。/流水线运行工夫中位数:视业务有异同,通常状况下[1-15分钟]是个不错的区间,体现平台价值,反映高频操作是否高效。/上线工夫中位数:视业务有异同,通常状况下[1-10分钟]是个不错的区间,体现平台价值,谋求极致,这里要越快越好。/用户负反馈次数和投诉次数的二次方:[1~N次], 器重用户反馈,器重与业务的沟通和分割。每一次负反馈都要足够的器重和反思。/需要均匀交付周期:[1~N天],指的是需要从确认到交付的整个周期的天数,反映平台建设的性能齐备度和平台整体提效的成果。 这个图是一些预设值对应的研发效力北极星指标的值,各位能够感触下,或者依照本人公司的状况来算个值,看看在哪个区间。 研发效力不同阶段侧重点体现研发效力的北极星指标次要用来反馈以后阶段与公司业务相干的外围指标,用来领导咱们的团队方向和工作重点。不同阶段,研发效力北极星指标应该有不同的侧重点。 在研发效力团队初期,业务重点在之前零碎的保护、治理和提供服务,那么研发效力北极星指标重点在周沉闷用户数、用户反馈,先要把本人手头的工作做好,再做后续的倒退; 而后团队的重点就要在之前的根底上有所突破,对公司有新的奉献,在需要交付、流水线、上线零碎等环节有切实的提效体现; 同时咱们还要器重效力度量的工作,器重数据积攒、度量和洞察;器重公司整体效力的晋升,齐备的工具链建设,继续改良。 尽管不同阶段业务侧重点不同,然而对于用户反馈的关注度,咱们要始终放在团队关注度的第一位,尤其是负反馈更要器重。 起步阶段 : 更看重沉闷用户数、用户反馈。成长阶段 : 可逐渐增强平台SLA等稳定性指标。成熟阶段 : 效率指标和需要交付可施展更大作用。本文小结本文首次提出八个研发效力北极星指标,并提出研发效力北极星指标公式,以便让你清晰理解公司的研发效力能力。同时本文提出了对于在不同阶段的公司,须要通过调整不同指标的比重来贴合公司的理论具体情景的办法。践行捕风捉影,让研发效力落地,让研发效力价值最大化。 我的其它文章如何疾速晋升团队软件开发成熟度,晋升研发效力?DevOps | 研发效力价值如何掂量研发效力负责人/研发效力1号位|DevOps负责人DevOps|AGI : 智能时代研发效力平台新引擎(上)DevOps|研发效力之环境、程序、配置、数据库变更治理

September 10, 2023 · 1 min · jiezi

关于devops:新兴DevOps操作系统Daggerio

一、Dagger.io是什么?最近关注到Docker创始人Solomon Hykes带着一众大佬来到Docker再次守业去了,搞了个我的项目叫Dagger.io,Docker当初如日中天,根本曾经垄断市场成为全语言DevOps的基础设施,而它的创始人却在这时候来到转而投身另一个我的项目,不得不让人好奇,于是理解了一下Dagger.io,它是一个才开发两年的全新DevOps 平台,其愿景用官网的话说是【构建DevOps的操作系统】。二、Dagger.io能够做什么?从Dagger.io官网的定义【Dagger is a programmable CI/CD engine that runs your pipelines in containers】来看可晓得,Dagger是一个能够在容器中跑pipeline的可编程的CI/CD引擎,能够做如下事件: 即时的本地测试可移植性:pipeline可在本机、服务器、jenkins等CI/CD工具上运行高级缓存:默认状况下会缓存每个操作与 Docker 生态系统的兼容性:只有程序能在Docker容器中运行,就能够利用Dagger.io构建pipeline。跨语言工具:能够应用DaggerIO来串联不同语言编写的程序,而无需学习各个语言。三、谁会应用Dagger.io?以下这几种诉求的人,应用Dagger.io会更好: 心愿编写代码来代替 YAML文件以组成pipeline。心愿用更弱小和灵便的货色取代各种手工脚本。编写自定义工具的平台工程师,其指标是跨组织协调继续交付。云原生开发者倡导者或解决方案工程师,心愿在短时间内演示简单的集成。

September 8, 2023 · 1 min · jiezi

关于devops:Seal梁胜近水楼台先得月IT人员应充分利用AI解决问题

2023年9月2日,由平台工程技术社区与数澈软件Seal联结举办的⌈AIGC时代下的平台工程⌋——2023平台工程技术大会在北京圆满收官。吸引了近300名平台工程爱好者现场参会,超过3000名观众在线上直播平台观看了本届大会。 数澈软件 Seal 联结创始人梁胜博士和江鹏受邀缺席此次大会并发表题为《AI时代的IT技术创新》的演讲,本文为演讲实录。     AI 正以不可逆转之势倒退这周二我去旧金山加入了谷歌一年一度的云计算大会(Google Cloud Next 23),这大概是我第8次加入这个流动,但往年与往届齐全不同。在往年的大会上很少谈及云计算的底层根底技术,也没有介绍 Kubernetes 的停顿,在近2个小时的主题演讲中简直 100% 的工夫都在议论 AI 技术。从这里,咱们能够看出 AI 技术给整个 IT 行业以及云计算带来了微小的影响。  为什么会有这么大的影响呢?从我集体过来十几年从事云计算畛域的体验来看,云计算基本上解决的是资源的问题。在没有云计算之前,如果须要资源,那么要购买机器、搭建机房,但云计算呈现之后,就不须要干这样的事件了。取而代之的是,呈现了 DevOps、Infrastructure as Code(IaC),这些新技术的呈现大大增加了企业对人力资源的需要。在这样的状况下,将来的 IT 行业可能会面临的挑战不再是优化机器资源,而是优化人力资源,包含 IT 的人力资源或 IT 以外的人力资源。因而,AI 成为了一个恰到好处的主题。    当初技术畛域的人力资源次要集中在两个方向:研发和运维。人员需要的方向定义了古代软件开发到部署、到运维、到降级的整个生命周期流程。我在上图的右侧列出了两个云厂商,但即使不部署在云上,部署在本地机器或者边缘设施上,整套软件开发流程并没有太大变动。  在过来十年中,甚至寰球经济不景气的当下,对 IT 人员的需求量仍旧十分大。这样的增长会不会持续呢?当初 AI 技术的呈现对这个增长会有什么影响呢?    咱们先从研发的角度来看这个问题。各位当初最为感同身受的可能是国内外的企业都在进行裁员,为什么会如此?  大家认真想想过来的业界倒退态势,比方挪动互联网,大家每天都在手机端上应用各种 App,那么认真回顾一下上次用到的新利用是什么时候?对我来讲,是有相当长的一段时间以前了。然而如果把工夫拨回5年前、10年前,那可能每过几天、几个星期可能就会下载一个新的利用,过后新的货色源源不断地呈现。但当初大家可能次要应用的只是各自畛域里的支流App,比方抖音、微信、B站以及各种网银之类的。  只管当初开发利用比以前容易得多,但长尾效应在缓缓削弱。  那么真正的研发当初去哪里了呢?从狭义来说,现阶段的研发是那些在各种大平台一直生产内容的网红,他们能够吸引很多用户。那未来的研发又会往哪个方向走呢?从当初生成式 AI 的角度来看,研发的方向会越来越多。无论是 AI 会帮忙研发,还是会间接被 AI 代替,AI 的倒退是不可避免的。  接下来,我来讲讲软件 2.0,这个概念是由一个从事人工智能开发的程序员提出来的,是指世界上越来越多的事件是由软件来实现的。  现阶段,大家能够用 AI 助手来帮忙生成一段代码,而后检查一下代码是否存在谬误,如果没有问题就能够用了。咱们大胆猜测:那么之后是不是能够用一个神经网或者一个 AI 模块来实现?可能你间接通知 AI 你要做什么,神经网就间接把性能实现了,甚至不须要看到代码。  AI 在将来5年、10年的倒退,会让很多设想的货色都成为事实,这对研发来说会造成很大的冲击。那么,未来研发人员的数量是否还会持续增长?我感觉毫无疑问,必定会持续增长,然而方向可能和当初有很大的差异。  DevOps 遇瓶颈,AI 来破局  我集体对 DevOps 行业十分有领会,因为之前我做过 CloudStack、做过 Rancher,这些产品都是为 DevOps 服务的,过来十年随同着云计算的疾速倒退,能够说是 DevOps 的飞速成长期,咱们正好赶上了 DevOps 的热潮。  ...

September 6, 2023 · 2 min · jiezi

关于devops:DevOps-|研发效能之环境程序配置SQL变更管理

本文次要是讲如何建设无效的环境、程序、配置、SQL变更和治理平台。 几天前和一个敌人聊到环境、程序的配置变更,SQL变更和整个上线流程。之前咱们在这块也做了很多,有做的好的也有做的个别的,借机都总结下来,心愿对你有用。 通常状况下,咱们最关注的也是最重要的局部是利用的变更,就是程序的部署上线公布这块,因为这部分最高频,每天上线很屡次的状况都能够产生,所以咱们在平台建设的时候也是优先做好这部分,然而对于环境、程序配置和SQL变更局部,通常状况下会优先级低一些,不是这些不重要,只是临时通过手工操作或者人力顶一下这部分的工作,最终这些问题是要通过平台自动化来解决的。 底层物理环境配置很久以前,计算资源老本昂扬,导致机器匮乏,很难做到「开发-测试-预发-生产」物理环境配置的对立。线上用高配的物理机,线下用低配的过保机器,甚至用虚拟机,这都是很常见的做法。不同环境之间物理资源的不同加大了环境配置的治理难度。比方一个Java 程序须要 4G 的内存,这在线上没问题,然而线下的虚拟机可能 1G 的内存都没有。同样的配置在两个环境中须要小心保护否则程序就崩了,所以常常有很多文档记录这些「魔法」骚操作,而后在操作环境时拿进去翻一翻。 当初随着计算资源价格下降、云计算疾速遍及,尤其是 k8s 的呈现,大大降低了放弃「开发-测试-预发-生产」环境一致性的老本,同时操作起来简便易行。所以工作中,咱们要「尽量」放弃这些底层基础设施的对立,这是做好下层很多工作的根底。 基础设施即代码(Infrastructure as Code, IaC)的呈现把环境配置的问题变得更简略。IaC解决的最大问题是基础设施配置和治理的自动化。之前通过手工操作来配置和治理的服务器、网络等基础设施通过 IaC 把基础设施配置和治理自动化,大幅晋升效率和可靠性。 应用代码治理基础设施,大大提高效率。缩小手工操作谬误。代码能够版本控制,具备残缺的跟踪性。自动化能够保障环境一致性。代码即文档,有利于团队合作。之前Google是把 IaC 放到代码仓库中,SRE管共性的配置,研发小伙伴来治理每个服务独特的配置局部,这也是一种办法。然而鉴于国情,我还是感觉让 SRE 或者 Ops 来管更适合,这样也有利于划清职责边界。 我倡议 1)梳理全公司的编译和运行时环境需要 2)把根底环境的固化到有版本控制的 Dockerfile中,3)而后研发效力平台援用这些根底镜像,最终达到编译和运行时受控。 编译时配置在编译源代码前,咱们通常会有一些编译时配置,要么写到配置文件中,要么通过传参的形式传进去,而后在编译时打到二进制程序外面。通常状况下编译时配置信息放到编译脚本中固化下来是个不错的最佳实际。比方咱们常常遇到的 build.xml, pom.xml, build.gradle等。通常这些构建脚本是研发小伙伴会开发调试时会用到,研发治理平台通常也会用到这些构建脚本,然而有时也会传入一些其它的参数。此时研发效力治理平台就会本人记录一份过后运行的命令,以便前面排查之需,比方保障制品的可重现。 所以在这里,咱们能够看到研发小伙伴会把大部分编译时配置放到构建脚本中,存在于代码仓库(repo)中和源代码一起进行版本治理;研发效力平台部署环境时,会从平台上传入参数进行「洁净的」编译,此时平台会记录一份编译时的配置。这两处的编译时配置信息都很重要。 运行时配置一旦咱们的程序或者软件部署实现,通常在启动时还须要读取配置文件或者读取数据库加载一些动静的配置信息,这就是运行时配置。运行时配置是能够动静调整的,无需从新打包和部署。 有的公司会把运行时配置也放到代码仓库中一起治理,尤其当配置信息比拟少,批改比拟容易时。然而一旦部署下来想要批改,就要把运行的实例(机器/容器)中的运行时配置都须要批改一遍,尽管有ansible,saltstack,puppet,但操作也会麻烦、容易出错且会导致平安问题。通常状况下研发小伙伴是没有手动批改生产环境配置的权限。如果想一次更改多个服务多个实例的配置,这就会是个大问题。随着服务的增多,配置的简单,咱们就会遇到如下的问题: 配置文件扩散:每个服务在本人仓库下保护一套配置,无奈对立配置和治理多环境配置文件难保护:通常「开发-测试-预发-生产」每个环境都有本人的一套环境配置,有的配置项须要对立,有的配置项须要辨别。配置文件无奈实时更新:配置文件批改后,必须重启服务能力失效配置,无奈实时更新,对用户不敌对。为了解决以上问题,通常公司会引入配置核心来解决,比方apollo,disconf,nacos,SpringCloud Config等。这些都是市面上比拟常见的配置核心选型。 首先把我的项目中各种配置全副都放到一个集中的中央进行对立治理,并提供一套规范的接口。 当各个服务须要获取配置时,就来配置核心接口拉取本人的配置。 当配置核心中的各种参数有更新的时候,也能告诉到各个服务实时同步最新的信息,使之动静更新 数据库配置,数据库变更治理咱们在上线利用的时候,通常也随同SQL变更,次要的需要 SQL上线审批流:做某些要害变更要有人审批,比方下级、DBA等SQL语句查看、审核和执行等:SQL语句要正确,执行没有问题角色和权限:只能查问和变更本人有权限的 DB能够试试Yearning/Themis/inceptior这三个工具,咱们也是在开源工具的根底上进行了二次开发,次要是买通了用户、权限和利用局部。之前申请个DB 还须要在数百个DB中去寻找,当初只有登录就会列出本人有权限的 DB。但这部分还没有齐全整合到咱们的流水线/公布单/上线单体系中去,这是一个须要持续发力的点。 对立变更流程和平台「生产->测试」环境之间的配置变更,通常由QA小伙伴来负责,比方把生产环境的表构造利用到测试环境。 「开发->测试->预发->生产」这样的配置升级流程通常由研发的小伙伴来实现。具体的状况阐明,能够参考我《研发效力之环境治理》的这篇文章。做好变更危险管控就好。 我集体感觉SQL 上线,配置文件上线,前端 CDN 都应该整合到利用上线流程中去,而不是独自有一个平台来承载。这样数据买通、角色和权限买通、流程买通,对立的体验和流程,解决了各种零碎间跳转带来的问题,进步了产研运各方的整体效力和工作体感,尤其是对于中小公司来说。

September 5, 2023 · 1 min · jiezi

关于devops:DevSecOps-中的漏洞管理上

DevSecOps意味着在DevOps交付管道把安全性蕴含进去。该模型尽可能早地将平安准则集成到软件开发生命周期的所有实用阶段中。下图展现了平安方面在DevOps前期阶段的集成,但DevSecOps安全性集成到生命周期的所有阶段。 IT平安领导者应该在他们的组织中采纳无效的破绽治理实际来施行适当的DevSecOps。 破绽治理破绽治理是一种帮忙组织辨认、评估、确定优先级并修复零碎中破绽的做法。最终,破绽治理的指标是通过应用修补、加固和配置管理等技术来升高破绽带来的危险。这有助于确保安全性,同时限度歹意用户可能利用的危险。IT平安的主要职责是防备破绽。咱们都晓得,安全漏洞可能代价昂扬;依据Ponemon研究所和IBM进行的联结钻研,每次数据泄露的均匀老本为435万美元,而85%的组织在2022年至多有一次数据透露。依据《2022年数据泄露报告》,以下是近年来十大数据泄露和十大数据透露属性。 破绽vs.利用vs.威逼了解破绽、威逼和利用之间的定义和关系十分重要。 破绽(vulnerability)是代码或软件中的缺点,为攻击者提供了未经受权拜访零碎的路径。在高层次上,破绽能够分为两种类型: 1.技术破绽:与代码相干的bug或谬误、配置不当的防火墙、未打补丁或过期的操作系统或基础设施等。 2.人的破绽:人们无意或无心地犯错误,并通过利用人类心理取得数据、零碎或包的拜访权限。 破绽利用(exploit)是黑客利用破绽的办法。利用破绽攻打是指一些恶意代码,用来攻打零碎的破绽。它可能会窃取信息,减慢/阻止零碎运行,或者成为服务器上的寄生虫,在将来制作问题。例如,Log4Shell破绽是Log4j程序容许用户依据本应打印在日志中的值执行任意代码的一个弱点。随后施行了许多不同的破绽利用,试图以不同的形式应用此破绽——其中一些破绽利用容许您插入本人的代码。相比之下,其他人裸露了软件的公有环境变量。 威逼(threat)是指一个或多个破绽利用破绽发动攻打的理论事件。 破绽治理和DevSecOps组合为了在DevSecOps我的项目中有一个良好的开始,在利用程序开发的晚期——最好是在开始编写代码之前——就集成平安指标。平安能够集成,并且能够在我的项目的初始阶段开始无效的威逼建模。当开发人员在代码进入管道之前查看代码以辨认任何问题时,动态剖析筛选器和策略引擎能够随时运行。这有助于开发人员立刻理解平安问题,使他们可能解决平安问题的所有权。一旦在动态应用程序中查看了代码,就能够应用SAST(static analysis security testing,动态剖析平安测试)工具执行平安测试,以辨认破绽并执行软件组合分析。应该将SAST工具集成到提交后的过程中,以确保被动扫描引入的新代码以查找破绽。因而,在软件开发生命周期的晚期集成SAST工具能够升高应用程序破绽危险。 在代码构建之后,就能够开始进行平安集成测试。在一个独立的容器沙盒中运行代码能够自动测试网络调用、输出验证和受权等内容。这些测试是DAST工具(dynamic application security testing,动静应用程序平安测试)的一部分。这些测试会生成即时反馈,从而可能疾速迭代以测试问题。如果发生意外的网络调用或未经污染的输出等状况,测试将失败,管道将以告诉相干团队的模式生成可操作的反馈。 拜访治理是须要与DevSecOps集成的下一个重要准则。咱们须要确保应用程序编写相干的安全性和性能指标。须要执行角色工程,定义与每个角色相干的角色和拜访权限——须要定义规范的天生权力角色。   平安扫描和破绽治理甚至在产品/我的项目投入生产后仍在持续。咱们须要确保通过适当的配置管理将主动补丁利用到产品的最新版本。确保产品运行的是软件及其代码的最新稳固版本。

September 5, 2023 · 1 min · jiezi

关于devops:连接未来驱动创新|腾讯云-CODING-DevOps-主题沙龙完美收官

点击链接理解详情 近日,由腾讯云 COIDNG 主办的“连贯将来,驱动翻新”主题沙龙在深圳圆满结束。流动现场,来自不同行业的研效专家汇聚腾讯滨海大厦,独特探讨了在一直改革的市场环境之下,组织研发效力晋升的前沿策略与实践经验。 流动上,Agilean 首席参谋、腾讯云 TVP 吴穹作为研效畛域资深专家,他示意:DevOps 的外围在于深刻思考和继续前行,在摸索 DevOps 的漫漫长路上,咱们在“修铁轨”的同时还要踊跃推动组织“改火车”,这样能力真正落地 DevOps 。另外,吴穹还谈到了 BizDevOps 的重要性。他认为,从 DevOps 到 BizDevOps 是一个极大的逾越,波及到整体组织的转型,须要顶层布局能力实现。 招联研发核心架构治理团队负责人田勇从多个维度登程,与大家分享了招联研发核心在研发模式对齐、效力平台整体设计以及落地计划推广等方面的实践经验,不仅为业界同仁提供了贵重的借鉴,也为 DevOps 在企业中的利用提供了新的思路和办法。 无限极 DIT 开发与测试中心测试与效力经理陈顺生基于 CODING DevOps 研发效力平台的实际,帮忙无限极实现了更加协同高效的团队合作,晋升了研发流程的可视化和透明度,从而减速了产品的迭代和交付。他分享了在整体流程中的教训,并强调了平台在落地过程中所遇到的挑战与应答策略。 英捷创软 CEO 徐磊在演讲中提到,随着人工智能的迅速倒退,如何将 AI 技术利用于软件工程畛域成为了一个重要的议题。他强调了 AI 在晋升软件工程效力方面的微小后劲,现场展现了 AI 在交互编码方面的翻新利用,并分享了他对于如何将 AI 融入软件工程实际的粗浅思考。 腾讯云开发者核心总经理刘毅对产设研协同的实质进行了探讨,强调信息对齐的要害,并基于多年来在腾讯积攒的实践经验分享了从全流程角度登程的跨角色沟通与解决方案,为产设研协同、跨角色沟通提供了新的视角。 在圆桌会议环节,嘉宾们聚焦 AI 和大语言模型给云计算和 DevOps 带来的影响,纷纷发表了本人的见解,并探讨了 AI 会如何影响软件开发人员的工作角色和技能需要。 探讨中,嘉宾吴穹强调开发人员需与 AI 共生,AI 的利用尚在倒退中,胜出者不肯定是 AI,而是能善用 AI 的人,踊跃拥抱 AI,与智能搭档单干晋升产能,是生存所需。嘉宾徐磊认为在 AI 的助力下,开发者作为一个垂直畛域的角色,得以专一于决策性工作,施展更大的创造性和决策能力,这个过程既促成了业务的翻新倒退,也推动了开发者角色的进一步演变。嘉宾刘毅则明确指出,客户迫切冀望通过 AI 来实现降本增效,利用 AI 满足事实业务需要,这一诉求具备极强的现实性。 此次腾讯云 CODING DevOps 主题沙龙为与会者提供了深刻的洞察和探讨,嘉宾们分享的丰盛教训和多元观点也为业界摸索将来的倒退方向提供了贵重的参考。 ...

September 1, 2023 · 1 min · jiezi

关于devops:活动预告-龙智紫龙游戏与JFrog专家将出席龙智DevSecOps研讨会探讨企业大规模开发创新

2023年9月8日(周五)下午13:30-19:45,龙智行将携手Atlassian与JFrog在上海独特举办主题为“大规模开发翻新:如何晋升企业级开发效率与品质”的线下研讨会。 在此次研讨会上,龙智高级征询参谋、Atlassian认证专家叶燕秀,紫龙游戏上海研发核心首席技术官王琦,以及JFrog解决方案架构师刘靖毅等嘉宾将为大家带来精彩演讲,分享寰球当先解决方案,以及大型企业开发中的最佳实际案例,为您提供实际参考,克服挑战,更快、更好地开发软件。 嘉宾简介: **叶燕秀龙智高级征询参谋、Atlassian认证专家** 叶燕秀是Atlassian白金合作伙伴——龙智的高级征询参谋,也是国内为数不多的Atlassian认证专家之一,她在DevSecOps、ITSM解决方案与工具链搭建,以及Atlassian系列产品的集成、部署等方面有着丰盛教训与独到见解。自退出龙智以来,叶燕秀及其团队先后为近千家企业提供DevSecOps征询、施行部署及培训服务,业余能力深受业界好评。 演讲主题:Jira DC:如何打造高效、智能、精细化的项目管理,赋能团队合作 演讲要点:她将帮忙大家解锁Jira Data Center版的诸多高级性能,帮忙企业实现更高效、更智能的项目管理,晋升团队合作与我的项目交付品质。 实现精细化项目管理晋升我的项目透明度、我的项目过程品质,以及多地协同办公的工作效率以流程治理为主,人治为辅的治理形式改革助力麻利落地,晋升企业竞争力嘉宾简介:**王琦紫龙游戏上海研发核心CTO** 王琦是紫龙游戏联结创始人、上海研发核心CTO,负责上海研发核心整体的游戏技术开发工作。他领有超过20年的从业经验,负责公司技术团队的搭建和治理。曾主导爆款手游《梦幻模拟战》的技术开发工作,负责太空科幻手游《第二河汉》的制作人及技术负责人,目前正在领导多款在研手游的技术研发及工业化施行工作。 演讲主题:Jira赋能游戏开发工业化 演讲要点:他将分享紫龙游戏应用Jira晋升开发效率和品质方面的实践经验。本次演讲将分为两个要害局部来开展全面、深刻的探讨。 第一局部:深入探讨Jira与Perforce、Swarm的协同利用,以及这种配合如何为开发流程带来弱小反对;第二局部:聚焦于公司版本开发生命周期,并分享紫龙游戏如何在Jira中进行二次开发实际。嘉宾简介: 刘靖毅JFrog 解决方案架构师 刘靖毅领有多年的一线国内中大型企业DevOps施行建设教训,他致力于帮助企业实现胜利的DevOps转型建设。作为JFrog中国的重要团队成员,他负责为客户提供全面的DevOps建设征询解决方案,以及推广最佳实际等工作。刘靖毅领有DevOps Master和CKA等多项认证。 演讲主题:JFrog如何减速企业DevSecOps建设 演讲要点:他将帮忙您理解企业DevSecOps建设所面临的挑战以及如何无效解决这些挑战。本次演讲次要分为以下四个局部: 企业DevSecOps建设面临的挑战支流的软件破绽攻打有哪些JFrog如何进行端到端的软件供应链平安管控DevSecOps开源治理施行案例最佳实际分享更多精彩流动等你来!除了精彩的演讲外,咱们还精心设置咖啡文化讲座及拉花展现环节,带您现场参观“设计之辩,为实在的世界设计”艺术展览,并特地安顿VIP交换晚宴,在更加轻松愉悦的气氛内与业界搭档进行更深刻的交换。 诚邀您缺席加入,与咱们共度一段难忘的时光。 流动名称:大规模开发翻新:如何晋升企业级开发效率与品质 日期:2023年9月8日(周五) 工夫:13:30-19:45 地点:上海市徐汇区东安路888号尚享会 · 橙生存,HADC艺术报告厅 如何返回: 地铁:12号线或7号线,龙华中路站6号口 打车:东安路与龙腾小道交叉口,东安路888号尚享会 · 橙生存 *流动参加须知:流动名额有限,先报名先得,敬请提前报名;请务必填写企业邮箱。报名数据提交后,龙智将进行审核,胜利报名将发送确认邮件;最终解释权归龙智所有。

September 1, 2023 · 1 min · jiezi

关于devops:DORA指标公司业务成果的占卜师

2009 年,受 John Allspaw 和 Paul Hammonds 在 Velocity 上演讲的启发,Patrick Debois 组织了一次名为“DevOps Days”的会议。晚期,公众对 DevOps 持有褒贬不一的认识且大部分企业高层人员对其并不器重。DevOps 本应将技术人员们团结在一起,却难以定义,更难以掂量,因而很难提出令人信服的反对或拥护理由。在这篇文章中,我将从 DORA 指标登程,摸索 DevOps 实际与业务成绩之间的预测分割。  DevOps 现状报告的由来2012 年,Alanna Brown 开始编写年度《DevOps 现状报告》。起初与 Gene Kim、Nicole Forsgren 和 Jez Humble 组成了一个弱小的团队。Nicole Forsgren 是一位具备丰盛钻研资格的博士,她领导了 2013 年至 2017 年的钻研工作。每年,该团队都会对寰球数万名不同工作角色和行业畛域的技术人员进行考察。他们查看后果、寻找论断、并颁布数据和他们的研究成果。他们的钻研论断经常受到很多人的关注。  如何在技术畛域进行性能基准测试?为了理解为什么有些团队的体现比其余团队更好,首先须要一个掂量 IT 团队“绩效”的规范。DORA 小组讨论了各种传统指标(例如代码行数、故事点和利用率等)所面临的挑战,发现仅依据集体或团队投入的工作来定义他们的绩效是有问题的。  因而须要抉择关注后果而不是产出。当他们这样做的时候,他们留神到了 4 个特定指标的独特之处,这 4 个指标涵盖了绩效和稳定性的均衡。这些指标被称为 "DORA 指标"。 部署频率(Deployment frequency)变更交付工夫(Lead time for changes)均匀复原工夫 (Mean Time to Recovery, MTTR)更改失败率 (Change failure rate) 当团队体现更好时,特地是在这些指标方面,他们看到了独特的、统计上显著的、可预测的业务成绩改善,包含: 盈利能力(profitability)市场份额(market share)生产力(productivity) 这种分割不仅存在于 "科技公司"(即以软件产品著称的公司),所有业务畛域都是如此。到 2018 年,高绩效的技术团队为每个企业带来了竞争劣势。更重要的是,DORA 持续探讨了其余 "非营利 "组织,在这些组织中,踊跃成绩并不齐全由银行存款余额决定。他们再次发现,DORA 指标是预测胜利的牢靠指标。  ...

August 30, 2023 · 1 min · jiezi

关于devops:提升系统管理监控和可观察性在DevOps中的作用

在一直倒退的DevOps世界中,深刻理解零碎行为、诊断问题和进步整体性能的能力是首要任务之一。监控和可察看性是促成这一过程的两个要害概念,为零碎的衰弱和性能提供了贵重的可见性。尽管这些术语常常能够调换应用,但它们代表着了解和治理简单零碎的不同办法。在本文中,将探讨监督和可察看性之间的差别,提供示例来阐明它们的利用,并强调各自的又是。同时,本文还将深入研究用于无效监测和可观测性的技术和工具。 监控:理解零碎状态监控的重点是收集和剖析无关零碎或应用程序状态的数据。它通常包含设置特定的指标、阈值和警报机制,以跟踪各种组件的性能和可用性。常见的监测技术和工具包含: 指标监控:应用Nagios、Zabbix、Prometheus和Datadog等工具监控预约义的指标,如CPU应用状况、内存耗费、磁盘空间、网络流量和特定于应用程序的指标。日志监控:应用ELK Stack(Elasticsearch、Logstash和Kibana)、Splunk或Graylog等工具剖析零碎不同组件生成的日志,以辨认谬误、安全漏洞或异样行为。综合监控:应用Selenium、Pingdom或New Relic Synthetics等工具模仿用户交互并监控零碎响应,以确保可用性和性能。可察看性:了解零碎行为可察看性采纳更全面的办法,通过剖析互相关联的组件及其关系来了解和解释简单零碎的行为。它强调答复问题和考察超出预约义度量的零碎行为的能力。可观测性应用的技术和工具包含: 分布式跟踪:应用Jaeger、Zipkin或AWS X-Ray等工具捕捉和剖析通过分布式系统的申请流。它反对辨认瓶颈、提早问题和依赖关系。应用程序日志记录:应用Fluentd、Logback或Log4j等工具收集具备上下文信息的结构化日志,以跟踪执行门路、解决问题并全面理解零碎行为。实时剖析:利用流数据平台(如Apache Kafka或Apache Flink)和可视化工具(如Grafana或Kibana)来解决和剖析大容量、实时数据流,以取得零碎性能洞察。监控和可察看性用例以下是监控和可察看性在DevOps中施展重要作用的几个常见用例: 应用程序性能监控(APM)监控:跟踪响应工夫、错误率和资源利用率等指标,以确保最佳性能。例如,设置CPU使用率高或响应工夫慢的警报。可察看性:剖析分布式跟踪和日志,以辨认性能瓶颈,理解依赖关系,并排除问题。例如,应用分布式跟踪来查明跨微服务的提早问题。基础设施监控监控:跟踪服务器指标(CPU、内存、磁盘空间)和网络指标(带宽、提早),以确保基础设施运行状况。例如,监督磁盘空间以防止因为磁盘已满而导致的潜在停机。可察看性:剖析日志和事件,以辨认异样行为或平安威逼。例如,应用日志剖析来检测未经受权的拜访尝试或系统日志中的异样模式。云资源监控监控:跟踪云服务(如AWS CloudWatch、Azure Monitor)的资源利用率和性能指标,以优化老本并确保服务可用性。例如,监督主动扩大组中已配置实例的数量。可察看性:剖析云提供商日志、跟踪和指标,以深刻理解云资源的行为并诊断问题。例如,应用可察看性工具来辨认无服务器架构中的性能瓶颈。继续集成/继续部署(CI/CD)管道监控:跟踪构建和部署指标(例如,构建持续时间、胜利/失败率),以确保CI/CD管道的效率和可靠性。例如,监督生成队列长度以防止出现瓶颈。可察看性:剖析来自CI/CD工具(例如Jenkins, CircleCI)的日志和事件,以排除构建或部署失败的故障。例如,应用可察看性来考察部署失败的起因。网络监控监控:跟踪网络流量、提早和数据包失落,以确保网络性能并辨认潜在问题。例如,监控网络带宽利用率以避免拥塞。可察看性:剖析网络日志、数据包捕捉和流数据,以诊断网络问题、检测安全漏洞或辨认异样行为。例如,应用可察看性工具来考察网络谬误的忽然减少。这些只是监控和可察看性如何利用于各种DevOps用例的几个例子。具体的用例和需要可能因零碎、基础设施和团队需要的性质而异。 总结监控通过捕捉预约义的指标和基于阈值的警报来提供零碎运行状况和性能的快照。它可用于检测特定问题或事件,并提供无关零碎或应用程序状态的即时反馈。可察看性提供了对简单零碎更全面的理解,反对被动故障排除和根本原因剖析。它侧重于获取上下文信息,揭示预约义指标之外的见解,造就继续改良的文化。实现可察看性通常须要额定的工具和架构思考,这可能会减少复杂性和资源需要。然而,深度零碎了解的益处以及解决未知或未预料到的问题的能力使其值得投资。监控和可察看性都是古代DevOps实际的重要组成部分,但它们波及零碎可见性的不同方面。监控提供了零碎运行状况的集中和即时视图,跟踪预约义的度量和阈值,而可察看性提供了对系统行为的整体了解,捕捉上下文信息并反对深入分析。 通过联合监控和可察看性技术并利用适当的工具,团队能够取得对系统性能的全面理解,及早发现问题,并一直优化其零碎。在监督预约义的度量和通过可察看性摸索不可预感的场景之间保持平衡,使团队可能在DevOps的动静世界中无效地治理和改良其软件系统的可靠性、性能和恢复能力。

August 29, 2023 · 1 min · jiezi

关于devops:Stack-Overflow开发者调查发布AI将如何协助DevOps

Stack Overflow 公布了开创性的2023年度开发人员调查报告 [1]。报告对 90,000 多名开发人员进行了考察,全面展现了以后软件开发人员的体验。接下来,本文将重点介绍几项重要发现,即重要编程语言和工具偏好、人工智能在开发工作流程中的利用以及这些趋势对 DevOps 畛域可能意味着什么。  2023 年开发者技术偏好考察结果显示,越来越多的开发人员开始在线学习代码。应用在线资源学习代码的比例从 2022 年的 70% 回升到 2023 年的 80%。只管许多开发人员(47%)依然领有计算机科学学士学位或同等学历,但这些趋势凸显了向其余常识解决方案倒退的趋势,尤其是对于年老的程序员而言,热门在线资源包含技术文档、博客、论坛和操作视频。  JavaScript 仍居榜首——它已间断 11 年成为最罕用的编程语言。值得强调的是,Python 已取代 SQL 成为第三大编程语言。"自 2015 年以来,SQL 始终稳居前三位(JavaScript、HTML/CSS、SQL),因而它跌落到 Python 上面是件小事,"Liuzzo 说。"依据咱们公共网站上的发问数量,咱们曾经看到 Python 的受欢迎水平在回升,所以咱们始终在期待一些变动。"  过来几年,TypeScript 和 Bash/Shell 的使用率也在持续增长。这两种语言波及其余风行编程语言的性能,因而它们在程序员中十分受欢迎。  PostgreSQL 也超过 MySQL 成为最罕用的数据库类型。在网络框架方面,Node.js 和 React.js 是最次要的。其余如 jQuery 和 ASP.NET 框架,则有过期趋势,可能是因为它们是较老的网络框架。  聚焦人工智能新人工智能翻新的暴发,例如大型语言模型(LLM)和聊天驱动的生成人工智能工具,对往年的技术发现产生了重大影响。事实上,83% 的受访者在过来一年中应用过 ChatGPT。其次是 Bing AI(20.6%)、WolframAlpha(13.36%)和 Google Bard AI(9.86%)。GitHub Copilot 被评为最罕用的人工智能开发工具。  在学习编码的人群中,应用人工智能工具的人数显著激增,他们通常关注到的是放慢学习速度、进步生产力和效率等益处。将其与他们目前如何应用 AI 工具进行调试和获取帮忙 (68%) 以及理解代码库 (50%) 相结合,报告发现其中的共同点是 AI 工具能促成学习。  尽管如此,人们还是对人工智能的准确性持狐疑态度,只有 13% 的人认为进步编码准确性是应用此类工具的益处。尽管这些痛点可能会随着 LLM 的倒退而失去解决,但就目前而言,仍须要人类的判断来捕获谬误和防止误用。  ...

August 28, 2023 · 1 min · jiezi

关于devops:质量管理-|-QCQAQM去QA化与降本增效

当初国内职业的品质治理都是从 CMMI 和 ISO 质量体系演变过去的,然而能做真正的品质治理的公司很少。品质治理的 QC 偏测试,对最终的产品负责;QA 偏过程,从过程把控品质;QM 偏体系,相似于全面品质治理,建设品质文化。 硬件公司更关注品质品质是一组固有个性满足要求的水平。品质就是符合要求;品质治理外围是人;CMMI外面要求的这种品质,之前在中兴通讯是符合要求的。然而起初,中兴推广麻利,品质管理人员转为麻利教练,前面的事件就不太理解了。[麻利后的品质怎么治理?] 在业界,个别有QA岗位的公司很多都是兼职,也有的干的都不是品质的事件,只是挂个名。 也有的把质量部的同学都叫做 QA,不分那么细 品质领导很要害有品质意识的领导,会组建业余的品质团队,来把控研发过程;不懂的领导会感觉,这些人没有产出,没有价值……同时也对品质团队的领导有要求,怎么体现出本人和品质团队存在的价值  ### QA指标哪里来 我当初的公司有QA团队,刚开始还感觉怪怪的,原来是业余的配置。只是这个QA团队制订的指标常常被开发团队所诟病;也不晓得这些指标是从哪来的? CMMI外面的过程域,品质和配置管理都是CMMI-2外面的。里边有规范和指标。 做得好的,会先出计划,领导评审,找团队试验,改良,推广;不好的,就是领导想啥就是啥,其实背地都是某个领导的要求;CMMI外面还有一个EPG,这个才是过程改良的,主导和推广规范,只不过,大多数让QA来干 品质和配置贯通始终厉害的品质管理人员,会一步步建设品质框架,把需要-开发-测试-上线,这些过程数据实现闭环,不会呈现专门考核开发或测试的状况;品质和配置一样都是贯通于研发过程中。 品质更要求独立,以第三方的角度对过程把控,所以也就要求品质团队要有间接向大领导汇报的权力;在一个公司外面,品质间接归属于大领导的架构,阐明还是要业余一点;如果是挂在产品、开发、测试,上面的,那就完了,根本就是从属和工具 这里说的品质,曾经不是产品质量、测试保障的品质了;独立于产研运测独自运行才行,然而独立进来又很难做。 这个就要看品质团队领导了,业余的领导会展现出品质的必要性;个别的品质人员如果只能做一些根本的工作,那就不行了 集体愚见:一般来说,有QA的公司,流程会业余一点;有CM的公司,流程肯定是业余和规范的;之前看一个精益专家说,公司的流程就是一个公司治理的体现 很多测试只做测试,或者关注测试品质。很少会关注研发过程中的品质 从兽性来说,人很多都会高看本人,低看他人;比方,不理解品质的会说,品质不就是干**的,就这个咱们测试或产品也无能呀,还要养这些人?而后他们接过去之后,干着干着就干没了 特地是制造业,像华为中兴,品质是他们的策略之一,所以绝对要求会很高;汽车也是,因为一旦呈现事变,那就是小事;已经某个大公司IPTV出事变,董事长亲自上门赔罪 得了去QA化的病艳羡有QA团队的配置,做私有云IaaS这块,品质这块都是研发本人负责;过后福报云是学 Google 去QA团队化,认为品质是研发的一部分,由研发 RD 本人负责, who run who build。不设置专门的QA和SRE岗; 然而 Google 给工程师的待遇,和国内公司的是不一样的;所以他们的能力也是不一样的 批准,也是艺高人胆大,Google 这么做下限高然而上限也低呀。不要轻易学习,画虎不成反类犬。字节就是这个故障[捂脸] 打消节约而不是降老本华为的狼性文化,给员工喂得的是肉;而那些要学习的公司,甚至连草都不想给 何止是草啊,连水都不给喝。 我司当初厕所都自带纸[捂脸] 应该降的,不是老本,而是节约。 能看得见的都是老本,减就对了 在业务人员眼里,QA 也是老本,不能发明收益…… 在业务人员眼里,SRE 也是老本,不能发明收益…… 在业务人员眼里,研发也是老本,不能发明收益…… 这不是降本,这是盘剥。 很多老板眼里只有能发明营收的销售才是帮他赚钱的;研发什么的都没用..... 吐槽小结后面探讨的还是很粗浅,前面一转移到降本增效上来就偏了,变成了吐槽「资本家」不喂肉,不给水,不给厕纸,甚至把除了销售人员的QA、研发、SRE都当成了老本都要减,至此吐槽完结。这就是咱们群探讨的内容,一群身在光明脚踩光明的打工仔,退出咱们一起来探讨吧 :)  我的相干文章DevOps|AGI : 智能时代研发效力平台新引擎(上)质效晋升 | 聊QA与业务测试(中)研发效力组织能力建设之个性团队FeatureTeam(上)DevOps|研发效力不是老板工程,是开发者服务质效晋升 | QA不做业务需要测试,你怎么看?互联网公司研发效力/工程效率团队建设和布局

August 25, 2023 · 1 min · jiezi

关于devops:质效提升-|-聊聊QA与业务测试

下面一篇文章《质效晋升 | QA不做业务需要测试,你怎么看》次要探讨的是QA 和业务需要测试相干的问题,文章收回后收到了很多小伙伴的反馈,这里把很多有意义的反馈放在上面,心愿对你有用。 约翰同学:QA 和测试的职能不同吧。很多时候混同了?scmroad:是的,对于国外来说QA 和 Tester,区别很大;但在国内很多场景下QA=测试人员约翰同学:每个公司对“QA”的角色职责定义不一样的。咱们公司 QA 就是不懂代码,不懂开发,不懂测试,只搞流程、度量、方法论等。scmroad:不懂代码,不懂开发,不懂测试的人去搞流程、度量、方法论?这样的人成长门路是啥?大学毕业就去做流程、度量、方法论,始终升上来的么?这样的人弄出来的流程、品质、方法论靠谱么?约翰同学:后面说的“不懂”是夸大一点的说法,大部分不是一毕业就搞流程啥的,个别会有一点开发、测试经验,然而工夫一久,开发测试方面教训其实是跟业务理论根本是脱节的。scmroad:我身边搞流程优化,度量改良,方法论这套的都是特地懂这块特地资深的人,不会是懂一点开发和测试的人去做这些。否则容易在行领导外行。约翰同学:认同你的观点。但某500强现状就是这样[允悲] jw同学: 哪家公司 QA 不做业务啊,那也太爽了 scmroad: QA部门必定有QA做业务的需要测试,关键在于这部分人在部门的比例,相对数量是否能撑持业务的倒退。 小猫咪同学:做业务需要测试的是QC,QA其实是相似于PMO的职能部门吧。自身也是做流程,做研发效力这块。 scmroad: 如果细说的话, QA和测试人员区别很大;但在国内很多场景下,QA=业务测试人员,而QA和PMO的区别就更大了,两者很多时候不是一个部门的。 小猫咪同学:这就要看公司的组织架构了,比方华为,QA是独立进去的部门,次要负责的就是做流程标准这块,在产品线内与PMO相辅相成打配合的,pmo负责需要进度老本,QA负责流程品质标准。这种QA就与业务测试简直没有关系了。 scmroad: 国内还有其它家是这样组织架构和划分职能的么? 小猫咪同学: 华为中兴光荣小米都是有的,只是可能各个公司之间对于QA的业务职责领域会有一些差别,然而必定还是区别于业务测试的。自身QA这个概念也是从制造业那边过去的,所以可能起源于制造业的公司会更偏向于这样设计。包含各大车企其实也是相似的概念,车企的话搞的是ASPICE那套。[题外话:当初很多车企又开始搞IPD了] 钟同学:看我的项目状况的。我是游戏的 QA 而且就是不做功能测试的,是因为18年开始游戏越来越简单技术难度越来越高。游戏的品质要求也高了,举个例子当初一个投资千万一年半左右的我的项目。须要留神的指标有: 兼容适配(分辨率,不同屏幕,不同图形接口,不同等级硬件,不同零碎版本当初还好都是64零碎了……)帧率和卡顿状况(30,45,60,90,120)内存应用状况包体大小(资源冗余,首包和分包……)硬件功耗(手机温度,cpu和gpu频率)至多实现下面 5 点你能力到前面的性能和玩法还有体验吧。而且须要精确定位道具。所以18年后游戏开始有一堆不专一测试性能的 QA,因为这些测试的复杂度和环境构建难度是十分大的。要求测试会局部白盒还有灰盒,须要测试会应用引擎编辑器以及引擎工具,还要会接入sdk,还须要你懂硬件,因为局部工具是硬件供应商提供的性能测试软件比方 intel 的 gpa,n卡和a卡的工具,高通的 mtk 华为的工具。还有引擎自带工具 unity 的uwa和upr以及profile。ue的ins和profile…… 所以 QA 变得非常复杂和宏大,以至于大公司当初都独自开个子公司把 QA丢进去 惊艳同学:那为啥开发具备这些能力,没有的须要学习。测试须要这些能力不具备就能够不须要呢? 钟同学:因为测试的门槛低,入门只有会黑盒就行而且测试工资非常低。不做技术测试就往项目管理走。所以上上限不一样。[话中有话:测试工资太低,只进行一些简略的黑盒测试,而须要更多技术和常识储备的游戏业务测试交给研发或者更业余的公司去做。] 关同学:能测出bug才是测试人员的外围能力,其它的都是辅助伎俩,太强调一些乌七八糟的指标都是给老板看的,当然测试角色没有老板反对也会过得很难,所以这些本末倒置的货色也是局势所迫。 吹个泡泡同学:好多面试问的问题都懵了,当初测试是不必干活了吗?怎么搭建品质管理体系?怎么进步测试品质?怎么评估测试品质?怎么让所有人都能高质量实现测试?怎么治理测试用例?怎么评估测试用例?如同把这些弄好了就行了不必干活了。以前没有这些乌七八糟的标准流程,大家反而很谐和。 大水母同学:没有业务要开你太简略了,和业务绑定可能还会让人忌惮,效力这种事属于有最好没有也不是不行的范畴。 scmroad:批准,须要对业务有价值,不能成为无根之水 Jack同学:如果是测试,必定是要做业务测试。如果是QA,的确能够不做。层面不一样。业务测试只是保证质量的一种形式。如果通过其余形式能够达到同样成果,甚至更好,那就是QA的价值。 duoxier同学:我狐疑你在说咱们然而又没证据。[咱们的QA就不做业务测试,在搞流程、卡点、标准.....的事] 我的想法QA(在这里特指测试)是一个十分业余的畛域,须要业余人员来做。业余的人做业余的事。尽管一开始能够找多面手来做一些调研、预研,但一旦上了规模,还是要业余的人来做,做的好且快。郭德纲老爷子有句话说得好,不要用你的业余爱好,挑战我的业余。 闻道有先后,术业有专攻。某些人认为本人的业余爱好技能曾经比人家赖以生存的技能还牛的人,千万别去挑战人家,本人在家里比划比划还能够。因为在业余的人士眼里,你的业余只不过是一个风趣剧。- 郭德纲 我的相干文章质效晋升 | QA不做业务需要测试,你怎么看?DevOps | 产研协同效力晋升之评审、审批流、品质卡点DevOps|从腾讯TEG CDC遣散聊技术中台什么是研发效力?研发效力定义及外围价值互联网公司研发效力/工程效率团队建设和布局

August 24, 2023 · 1 min · jiezi

关于devops:3个视频教你如何正确使用华为云CodeArts-PerfTest

华为云性能测试服务CodeArts PerfTest是一项为基于HTTP / HTTPS / TCP / UDP / HLS / WEBSOCKET等协定构建的云利用提供性能测试的服务。反对疾速模仿大规模并发用户的业务顶峰场景,能够很好地反对报文内容和时序自定义、多事务组合的简单场景测试,测试实现后提供业余的测试报告,将性能压测自身的工作继续简化,帮忙客户将更多的精力投放到业务和性能问题自身,同时降低成本,晋升稳定性,优化用户体验,帮忙企业晋升商业价值。 为了让您更好地理解并应用CodeArts PerfTest,本文将通过3个短视频为你介绍CodeArts PerfTest的个性实际操作。 体验通道:https://www.huaweicloud.com/product/cpts.html 01千万级性能压测引擎,助力极致性能压测CodeArts PerfTest性能测试服务提供千万级集群超大规模并发能力,涵盖超高并发刹时发动、梯度加压、动静压力调整等能力,满足亿级日活利用的压测要求,企业能够灵便按需进行高并发测试,提前发现性能问题,保障产品上市品质。https://www.bilibili.com/video/BV1uu411n7kA/?aid=531985818&ci... 02八大特色压测模式,实现全面性能压测CodeArts PerfTest性能测试服务积淀了30年高并发测试工程计划与实际,提供了浪涌(突发流量)、智能摸高(零碎性能摸底)、震荡(模仿高下峰)、TPS模式(压力自定义)等8大模式,疾速构建实在场景,助力产品压测场景覆盖率晋升50%。、https://www.bilibili.com/video/BV1yV4y1e75c/?aid=871983178&ci... 03智能化性能测试报告,帮忙剖析决策CodeArts PerfTest性能测试服务提供多维度指标的压测报告,蕴含TPS、RT、SuccessRate、TPxx、StatusCode、执行日志等20+性能指标,接入实时资源和调用链关系的可视化数据分析,全方位评估性能指标。 https://www.bilibili.com/video/BV1UN411b7P5/?aid=489426329&ci... 得益于以上个性,华为云CodeArts PerfTest现在已广泛应用于金融、车企、互联网、政企等畛域,帮忙企业预估性能容量基线,正当利用资源,晋升服务稳定性,为企业倒退夯实根底。 如华为云CodeArts PerfTest专家团队帮助海内某通信平台,通过模仿业务10大外围千万级并发的实在业务场景,达成1亿日活架构优化的指标,晋升资源利用率200%,节俭用户老本百万美金,无效保障业务急速扩张10倍,达成公司战略目标。 将来,华为云CodeArts PerfTest将一直积淀企业应用性能看护的最佳实际,提供一体化智能压测体系解决方案,继续晋升关键技术竞争力,守护客户产品稳固,助力客户商业胜利。

August 24, 2023 · 1 min · jiezi

关于devops:为了那1分钟的追风少年到底经历了什么

6月15日,梅西在新工体闪耀全场。但,有一个比梅西更闪耀的少年。他跳下了看台,冲进了阿根廷和澳大利亚的比赛场地,和梅西紧紧相拥。虽漏掉了洛塞尔索被动伸出来的手,但他显然指标明确,一路狂奔到禁区和大马丁击掌,又通过风骚的走位绕场跑回了门前,和阿库尼亚 Hive Five。他令全场沸腾,为他高喊加油。整个过程差不多继续了1分多钟,直到“追风少年”跑累了,被动躺到地上被保安抬出去。被抬出去的时候,他仰天大笑。所谓高兴到飞起也不过如此,隔着屏幕咱们感触到了他的满足和高兴。谁说中国足球不行?看看中国球迷就晓得了,前锋的速度,中锋的麻利,后卫的耐力,守门的体格,一个人就整出了一个球队的声势。现场的七八个保安一边追一边笑,不晓得是真的跑不动还是真的不想追,他身后那个保安大哥像藏不住外面衣着阿根廷球衣一样藏不住他的欢畅。仿佛全场都在偷偷成全这个少年,看着他以风骚的跑位绕满全场,和球王拥抱,与门神击掌。而貌似追不上的保安大哥,也以另一种形式,实现了本人的欲望。明天有音讯称这位追风少年被行政拘留, 然而官媒报道中却掺杂着几分对追风少年行为的认可。这次事件也循序传遍了全世界,外媒也进行了相干报道,大多数的人都带着赞叹的态度。预先这位“追风少年”也通过视频进行了赔罪,他说他太爱梅西了,通过正规渠道和偶像合影太贵了,只能采纳这种形式,据说和球王梅西合影要十万。有网友扒出了这位追风少年的一个非凡身份:数学建模获奖学霸。他对整个“追风”过程包含球赛的场地、门路、排位都是精心计算过的,包含他要开始“追风”的那个最要害的一刻,因为开始了就没有后退,而且必须要胜利!其次,“追风少年”每天都跑1000米,为什么是1000米?很显然,“追风”的途程也就在600-1000米,也不会太边远,所以按1000米坚持不懈一直训练也就是为了“追风”那天筹备的,而且很早就开始了筹备。接着,准备充分、锁定目标、明确机会就要开始口头了。口头兴许会失败,而且可能后果很蹩脚且一发不可收拾。比方他跳下3米高楼台的时候就摔断了腿,或者跳下来后还没跑出去10米就被眼尖的藏在暗处的国外保安给摁住了,再或者整个“追风”过程事实与筹备的天壤之别,没能给梅西来个拥抱和大马丁击个掌。然而开始了就是开始了,那个时候在心理上就不能有任何踌躇,所有按着本人的心田和筹备开始。最初,后果是圆满的,也是无悔的,此刻或者是他人生中最幸福快乐的一刻。他的这次口头,也让遵守“生存规矩”的咱们从新思考了什么是真正的幻想和激情,什么是真正的怯懦和保持。谁的幻想不疯狂呢?这不,在技术圈,也有这样一群软件工程师,他们也是研发效力畛域的“追风少年”。他们热爱研发行业,是最早接触研发效力的一批人,他们想同研发行业的从业者分享本人这些年看到的研发畛域的改革经验,他们精心筹备了当下最火的研效认证教训,致力于帮忙更多研发效力畛域的小伙伴追梦。 软件工程师的真、善、美真: 坚持原则,不轻易斗争; 捕风捉影,不说实话; 认真负责,不放过细节。 善: 科技向善; 谋求卓越; 对更好办法一直谋求。 美: 对“美妙”地一直谋求; 好的代码、文档、产品是柔美的。 他们始终在谋求、践行真、善、美的价值观,幻想通过软件或者代码做出一些优良而且靠谱的产品,使客户受害。 晋升研发效力,打造外围竞争力家喻户晓,很多工程师因为不足对软件工程方法论、端到端研发效力晋升方法论的学习,进而导致低效和低质的实现工作。当然,这其中也包含团队规模小、团队成员技能无限、事项繁冗等问题,导致资源稀缺,进而产生很多问题。 这时候,这些行业大咖的助力能够帮忙研效路上的咱们少走一些弯路。他们在研效畛域始终在谋求更高效、更高质量、更牢靠、可继续地交付更优的业务价值。具体来讲: 01 对组织 更高效:更高的效率代表更快、更及时地交付,这样就能更早地进入市场,而后更早地学习、更早地调整,更早地升高危险,更早地锁定停顿和价值。这是麻利和精益思维的外围; 更高质量:咱们研发的产品是有品质红线、有底线要求的。疾速交付给客户有品质问题的性能除了会引发投诉以外没有任何价值。品质是内建的,不是预先测验进去的; 更牢靠:咱们要的是麻利,而不是软弱(agile rather than fragile),平安和合规方面要有保障。就像开车一样,只有车子更牢靠、刹车更好,你才敢开得更快; 可继续:短期的取巧和”快糙猛”、小作坊式开发,只会给将来带来更多的技术债权和长久的效率低下,软件研发不是一锤子买卖,咱们应该用”长线思维”来思考问题; 更优的业务价值:咱们常常说”以终为始”,你提供给客户或业务的货色应该是有价值的,这是对于你为什么要做所有这些事件的基本出发点。 02 对集体 强调功绩而不是苦劳:大家能够将指标聚焦在对后果有帮忙的事件上,即交付业务价值;着眼点从部分产出过渡到整体后果上; 强调更聪慧地工作:通过一系列工作流程、合作形式、角色职责、零碎架构、技术平台上的优化,通过工具建设和自动化水平的晋升,让大家可能解脱简短无聊的各类会议、反复机械的手工操作,把工夫花在真正有创造性的事件上; 强调集体能力成长:优良的企业会重视偏重造就集体的技术能力、软件工程能力、业务畛域能力。 所以,只有每个人的效率和能力晋升加强,整个组织的研发效力才会更好。更多对于端到端的研发效力外围能力咱们一起来看看: 5大部分认清研发效力工程师所需的真正技能01 你是否把握了上述的全副技术外围? 研发效力和软件开发一样,都有很大的灵活性,进步研发效力不是生吞活剥就能做好的,只有理解实际背地的原理,能力灵活运用。 由IDCF社区与王立杰、杜伟忠、陈老师、徐磊、陈晓鹏、庄俊乾、赵舜东等业界多位出名专家讲师,联合国内外多个实在案例,精心设计的《研发效力(DevOps)工程师》培训课程体系笼罩了上述所有的知识点,力求贴近实战,实践性强。02 为什么要考取研发效力认证 证实本人的实力和业余素养,正如追梦少年个别,考据路上没有捷径可走,所有的胜利都是汗水与付出的回报。证书是官网认证的,具体来讲: 官网认证:工信部受权国家级别证书,证书颁发:工业和信息化部教育与考试核心,证书一生无效; 人才缺口:紧随国家人才倒退策略、行业发展趋势,造就研发效力畛域专业人才; 无业余限度:工作年限满2年即可入行,取得职业技术认证,扩大职业倒退与降职之路 灵便实用:线上授课365天内可重复观看重复学习,线上考试无地区限度节俭备考工夫。 03 学习完此课程后,你能够 取得职业资格认证,扩大职业倒退与降职之路; 业界最顶级讲师阵容打造的精品内容; 晋升认知程度,紧跟数字化时代脉搏; 把握端到端研发效力晋升办法与实际; 扩大人脉,结识行业大咖与业界同济。 04 课程面向人群 从事研发效力(DevOps)相干的治理与技术人员,包含企业主管、研发总监、项目经理、产品、架构、开发、测试、运维、经营、麻利教练、工程教练等角色。 05 培训信息 开班工夫:2023年6月20日、7月20日、8月20日 课程时长:45课时,每课时45分钟 培训模式:线上授课+在线答疑+模拟考试+考前辅导 参训人数:20 人小班精品课程(反对企业独立开班) 授课语言:中文授课+中文考试 06 考试信息 考试地点:集中考试,老师监考 考试模式:线上闭卷考试 考试题型:判断题、单选题、多选题 IDCF 荐读丛书:《麻利无敌之 DevOps 时代》、《京东麻利实际指南》、《运维窘境与 DevOps 破解之道》、《PMI-ACP 捷径》、《数字化时代研发效力跃升办法与实际》等。 ...

July 13, 2023 · 1 min · jiezi

关于devops:研发效能谈敏捷开发团队转型中的协作化与自动化

作者: 杨凌宇(现就职中国电信研究院) 研发效力(DevOps)工程师认证学员 前言在现在软件开发流程和工具愈发成熟的现状下,麻利仿佛是所有软件产品团队后退的指标。很多团队都声称本人是麻利团队,但实际上,他们更多是在肯定水平上达到了麻利。咱们在麻利实际的过程中,总会与现实中的状况存在差距,所以咱们更多要思考的不是怎么彻底的达到麻利,而是在以后的理论状况下,怎么更好的使用麻利的思维去改良。麻利涵盖的范畴十分广,从需要收集,到产品设计、开发交付、测试平安、运维保障等一系列流程,都能够使用麻利的思维。其中开发交付的过程,是真正建设出一个产品的过程,我作为一名一线的开发人员,也更想谈一谈在开发过程中,以及对于开发团队来说,如何进行麻利的转型。 何为麻利开发麻利开发是以用户的需要为外围,把大的需要进行拆分,采纳迭代式的办法进行开发,使软件始终处于可公布状态。麻利开发离不开团队单干。在任何模式的团队中,大家都会强调“teamwork”这个词,麻利开发团队的一个重要思维其实也是“teamwork”,咱们称为“协同”。 在一个Scrum团队中,有产品设计人员、开发人员、测试人员等,大家协同工作,以此形成了产品的残缺生命周期。在大团队内有大团队的协同,在小团队也要有小团队的协同。对于开发团队来说,当其内的开发成员可能在麻利上达成共识,劲往一处使,这样造成的合力才是最大的,这个团队才算是开始走向麻利。在这之后,团队独特抉择适合的麻利开发工具,定义麻利开发的流程和标准,使得麻利思维可能真正落入到麻利实际中,从而实现团队的麻利转型,并可能继续低成本高效的交付价值。 麻利开发团队的核心思想早在2009年,Flickr在演讲中提出了一个十分重要的理念:“一个核心,两个基本点”。其中两个基本点一个是保持合作化,一个是保持自动化,那么在麻利开发中,这两个理念也同样实用。合作化是进步生产力,自动化是进步生产效率,其指标都是为了继续低成本高效交付价值。那么一个开发团队在向麻利转型的时候,重点思考的就是这两个点:进步合作化、进步自动化。 进步合作化进步合作化,须要团队成员造成协同的理念,达成协同的共识。在传统DevOps(开发运维一体化)中,把开发和运维的各个阶段串通了起来,强调的是开发人员和运维人员的协同。在开发团队外部,须要各个开发成员之间的协同。间接给团队灌输合作化的思维是难以扭转的,但能够采取以下的一些理论的措施,去促成团队的合作化口头。1、多沟通和交换。在很多公司中,一个开发团队往往是坐在一起的,甚至是在一个绝对独立的会议室中围成一圈办公,这个就是一个最佳实际。在很多人的传统印象中,开发人员比拟少言寡语,他们喜爱专一在本人的世界里默默开发,不太违心与人交换,而这可能就是妨碍麻利的一个重要起因。在麻利中强调个体与互动,当大家可能坐在一起开发,可能face to face的去沟通,就能疾速解决很多问题。例如对以后的开发需要了解是否到位?以后开发遇到的Bug如何解决?以后的性能是否曾经有相干的实现能够复用?以后本人手头上的工作实现是否能够给予其余成员帮忙?如果大家都违心这样,就能施展出一个团队最大的价值,补齐了可能因木桶效应存在的短板,所有开发人员作为一个整体来交付代码,大家的常识和能力也失去了共享、晋升。在Scrum5个会议中的每日站会,也是为了增强沟通交流,拉齐信息,提出问题,寻求帮忙,其本质思维是一样的。而不足沟通和交换的团队,会造成极大的节约,如期待的节约、寻找信息的节约、移交的节约、尤其是对人才的节约(人的价值没有失去最大的展示和施展),对团队的效率影响是微小的。 2、多帮忙,少埋怨。一个开发团队中成员的技术水平不免参差不齐,作为资深的前辈,要可能在各个方面给予后辈帮忙和反对,而不是对其进行指责或埋怨。只有在团队中营造了一个互帮互助的踊跃的气氛,团队能力更快提高和成长,从而带来效率的晋升。 3、一起探讨选出适合的工作软件,制订适合的标准。开发团队中的每个成员在过往的经验中可能都有本人善于的软件和相熟的标准。然而在新的团队中,为了团队的整体合作,成员须要放下本人的偏好,独特探讨出最适宜整个团队的软件和标准,包含IDE、编码标准、Git提交标准、CICD工具、公布流程标准等。通过统一的工作软件和标准,增强团队的合作程度。 4、依据状况灵便调整计划。在麻利宣言中有这样一句话:响应变动高于遵循打算。在一个开发团队中,不可能百分百的依照打算进行开发,并且每个开发人员都有本人善于的技术局部和不善于的技术局部,这就导致每个开发人员的开发效率都是变动的。如果严格百分百依照打算排期开发工作,那么势必会导致闲忙不平均的情况。而如果要把打算先做到完满,那更是一件不太理论的事并且还要为此付出微小的精力。所以更好的状况是,开发人员对PBL有一个初步的工作排期后,便可进行理论的开发,也就是“stop starting, start finishing”。在理论的开发过程中,依据工作的难易水平和本身的状况,灵便应答,并且团队成员之间相互交换帮忙,这样能力最大化团队的开发效率。 所以合作化实际起来并不难,要害还是团队成员是否在协同上达成共识,把团队放在集体之上,有荣辱与共的价值观和使命感。 进步自动化如果说合作化是思维上的转变,那么自动化就是口头上的转变。通常来说软件开发过程也是整个产品的交付周期中最漫长的过程,所以其中能用到哪些自动化工具和伎俩进行辅助,如何进步自动化程度尤为要害。从一百天交付一个版本,到一天交付一百个版本,这是一个质的飞跃。其实,软件自动化的倒退通过了十分久的工夫和技术积淀。在以前,开发人员在本地编写好代码后,须要手动编译构建,打包成软件制品,而后通过脚本或者命令的形式部署到测试服务器上,有时还会因为服务器环境的问题造成部署过程中的各种异样。尽含辛茹苦部署胜利后,交给测试人员进行专业化测试。期间测试人员测试出的问题,开发人员修复后都要再反复一次上述的流程,耗时耗力,最初发现开发人员只有小局部工夫在真正写代码,更多工夫是在干一些重复性和繁琐性的工作。起初Jenkins工具的呈现,将继续集成(CI)和继续部署(CD)都做成了可自动化执行。开发人员在Jenkins上配置好后,只须要编写并提交代码即可,其余的步骤Jenkins都能帮忙解决。在部署环境上,因为开发人员是在本人的电脑上编写程序并调试运行,而后须要公布到服务器上,因为环境不统一导致的问题也总是让人头疼,起初呈现了Docker和K8S这些技术,解决了部署运维层面的对立和自动化治理问题。而把这些自动化的工具和技术联合起来,开发人员只须要把精力集中在代码解决上即可,前面的流程都能主动执行。 上述自动化技术更多聚焦于集成和部署层面,但其实,软件的自动化不止如此,在开发层面,其实也有着很多自动化技术。B/S架构衰亡后,更多开发人员开始做Web开发,然而大家可能要手写很多Web底层的代码,这些都是重复性的并且和业务没有关系,所以之后便呈现了许多Web框架,如Java中的Spring框架、C#中的ASP.Net框架。这些框架把Web底层的技术进行了封装,通过一些简略的配置即可实现很多底层逻辑的主动实现。此外,当初的IDE越来越先进和智能,咱们通过很多插件,在开发的过程中可能主动帮咱们生成代码,主动帮咱们查看代码和纠错等等。 所以这些自动化技术、工具、框架的呈现,让开发人员可能更聚焦于业务的实现,加重各种简单繁琐的工作,从而晋升了交付价值的效率。而且随着大数据、AI技术的愈发成熟,人们不再满足于自动化,而会向着更高层次的智能化后退。对于开发人员来说,如果可能把一些非核心性能的代码交给AI来实现,那无疑是生产效率的进一步飞跃。 合作化和自动化的联合合作化和自动化是麻利开发团队转型的两大重点,并且不能只看其一,而要将其有机的交融。 我曾有过一段我的项目经验,尽管我的项目团队也是依照Scrum的形式进行组建的,每天都会开每日站会来拉齐信息、同步工作进度,开发过程中的各种CICD自动化工具也都有应用上,然而整个研发效力还是上不去,其实就是合作化和自动化没有很好的联合起来。每个人都盯着调配给本人的那些工作,遇到困难时不会被动去进行沟通,而是本人闷着解决,这样就拉低了整个团队的进度。代码提交的时候不足评审机制,所有人都想着连忙把本人的代码先提上去,因为晚提代码的人要解决抵触这种烦心事,谁负责的功能模块出问题就谁解决,没有一种相互合作的气氛。外表上看这种如同是有规章有制度的模式,但其实却背离了麻利的思维。 所以当咱们基于麻利的理念去做开发时,大家都会用自动化工具是一方面,更重要一方面是,大家都会用自动化工具进行合作开发。 麻利开发的瞻望麻利开发的演进是一个过程,并且没有起点,它会永远朝着一个指标后退:让人的价值最大化。无论是团队协同,还是借助各种自动化工具辅助,实质上都是在一直地放大人的价值。随着开发团队逐步走向麻利,兴许他们每天产生的代码会缩小,但每天产生的价值肯定会减少。

July 12, 2023 · 1 min · jiezi

关于devops:Seal-AppManager-v02-发布进一步简化应用部署体验

通过近3个月的研发,Seal AppManager v0.2 已正式公布。  Seal AppManager 是一款基于平台工程理念的利用对立部署治理平台,于往年4月首次推出。在上一版本中,咱们曾经释出集成 ChatGPT 简化服务模板代码生成、云老本可视化、动静环境治理等性能,通过升高基础设施运维的复杂度为研发和运维团队提供易用、统一的利用治理和部署体验。  在此基础上,Seal AppManager v0.2 提供更灵便、弱小的利用和环境部署治理能力、优化交互操作并为企业用户落地生产环境提供了外围撑持,进一步简化利用部署治理体验。 收费试用:https://seal.io/trial 产品文档:https://seal-io.github.io/docs/    弱小的利用和环境部署治理能力随同云原生技术迈入深水区,企业外部 IT 架构演进得愈发简单,IT 团队规模一直扩张。在多团队合作的背景下,应用环境配置往往变得复杂且易出错,使得利用和环境部署成为产品团队面临的挑战之一。  利用和环境部署治理是 Seal AppManager 的外围,通过提供多样化的利用运行时反对、基于服务模板提供下层灵便的利用定义能力,简化利用和环境部署过程,减速利用交付,确保利用在跨环境中的稳定性和一致性。  晋升利用部署治理的易用性在上一版本中,用户能够从利用零碎的维度对立治理多个部署实例,进而简化利用管理工作,促成研发团队间的无缝合作。在 Seal AppManager v0.2 中,这一个性失去加强:  反对服务配置变更历史的比拟:新版本引入了配置变更历史比拟性能,使用户可能轻松查看和比拟应用程序配置的变更。这项性能不仅有助于疾速定位问题,还提供了可追溯的历史记录,确保配置更改的安全性和可靠性。  服务配置变更历史比拟  反对批量以及跨环境克隆服务:用户能够轻松复制现有的服务配置到单个或多个指标环境,同时反对克隆服务的参数定义,使得研发和运维人员无需陷入反复的配置工作中,晋升工作体验。这一性能的引入将确保跨环境条件下服务配置的一致性,晋升软件交付的可靠性。  克隆服务  优化服务和资源的操作交互:Seal AppManager v0.2 将改良服务和资源操作交互,用户将通过简化的操作流程疾速部署和管理应用程序的服务和资源。这项性能的引入将极大地提高工作效率,使其可能更轻松地掌控和操作应用程序所需的服务和资源。 加强动静环境治理能力在云原生技术迅速遍及的明天,混合环境部署已是大多数企业进行利用交付和公布时的必然选择,然而开发、测试、生产等多环境治理也带来很大挑战。  在上一个版本中,咱们曾经提供了动静环境治理的个性,借助该个性研发人员在不理解底层环境细节的状况下可能自助部署利用。在 Seal AppManager v0.2 中,这一个性失去进一步加强:  反对我的项目级别的环境/连接器治理:用户能够依据我的项目的需要,针对不同的环境和连接器设置和治理配置,实现更精细化的管制。这一性能的引入将使产品团队可能更高效地治理和配置不同我的项目的环境和连接器。 反对展现环境依赖图:环境内不同的服务之间存在依赖关系,Seal AppManager v0.2 能够通过可视化的形式出现不同组件和服务之间的关系。借助直观的依赖图,用户能够更清晰地理解环境外部组件的依赖关系并对相干资源间接进行操作,优化部署过程,进步整体零碎的稳定性。 环境依赖图  反对克隆环境:克隆环境能够依据现有环境的配置及服务,疾速创立一个新的环境,包含环境中的利用相干服务及基础设施资源。克隆环境创立实现后,用户能够在利用治理中应用该环境,被克隆的服务也会依据依赖关系主动编排部署,优化工作流程,极大节俭团队工夫和精力。  克隆环境  反对多层级的变量配置:在 Seal AppManager v0.2 中,用户能够在全局、我的项目和环境三个级别设置和治理变量或密文,不同层级的变量反对主动继承。这项性能使得在不同环境中应用程序的变量治理更加不便灵便,可轻松应答不同环境下的配置需要,确保利用的可靠性和安全性。 优化操作交互为了进一步提高交互的灵活性和控制力,Seal AppManager v0.2 引入了 Seal CLI 命令行工具。用户能够通过CLI与平台进行交互,执行各种操作,如部署利用、治理服务和环境等。这一性能的引入为用户提供了更多自定义和自动化的可能性。   为落地生产环境提供外围撑持为了助力企业用户落地生产环境,Seal AppManager v0.2 提供了Kubernetes 高可用性(HA)装置部署、RBAC(Role-Based Access Control)和多租户治理。用户能够轻松部署牢靠和稳固的 K8s 集群,并通过 RBAC 实现细粒度的角色和权限管制,同时利用多租户治理实现资源隔离和治理灵活性。这一性能组合为生产环境提供了更高的安全性和可管理性。  ...

July 10, 2023 · 1 min · jiezi

关于devops:认知负担的挑战与平台工程的机遇

开发人员与 DevOps 一直减少的认知累赘被认为是软件工程中最大的问题之一。随着越来越多的工具、框架和办法能够抉择,以及“You build it, you run it”的 DevOps 思维的倒退,咱们能够看到为了提供面向客户的产品和服务,认知累赘也随之大幅减少。  在明天的文章中,咱们将初步理解认知累赘的基本概念,一起探讨对于开发人员与 DevOps 工程师来说,他们的认知累赘来自哪里,平台工程将如何加重认知累赘并改良相应工作流程。  理解认知累赘通常来说人在任何给定工夫内能够解决的复杂性是无限的,同时存在于咱们脑海里的想法数量也是无限的,通常是在三到七个之间。而一些不必要但又不得不解决的信息或扩散手头工作的注意力也减少了咱们所解决的复杂性。复杂性还来自于咱们整合想法及概念以帮忙了解的过程。这些都形成了咱们在尝试执行工作时所须要接受的认知累赘。在心理学中,每种类型的累赘都有对应的名称:  外部认知累赘-因为工作外在难度而产生的累赘内部认知累赘-解决扩散注意力或不必要的元素产生的累赘附加认知累赘-因为建设对工作的了解而产生的累赘 随着对工作的相熟水平越来越高,当咱们开始整合了解并建设一个对于工作的更高阶心智模型,外部认知累赘将随之缩小。例如,当咱们第一次尝试驾驶时可能感到力不从心,即便在路况良好的状况下咱们也须要高度集中,这时驾驶给老手司机产生的外部认知累赘是极高的。随着对车况更加相熟且驾驶技术有所提高,开车这项工作所带来的认知累赘逐步缩小。当然,咱们的驾驶技能仍然会受到内部认知累赘影响,比方在开车时手机忽然响了等因素。  开发人员的认知累赘开发人员往往喜爱议论架构、形象和施行细节方面的事件。架构通常是整体想法或创意,也就是零碎如何在宏观层面上组合在一起。形象则是概括,也就是如何在架构中重用代码或组件。施行细节就是如何实现形象的具体版本。  这种层次结构容许开发者们在疏忽各种细节的状况下依然可能了解他们正在工作的零碎。通常来说,参加软件开发我的项目的每个人都应该相熟总体体系结构。在理论状况中,如果开发人员须要理解软件系统的所有细节可能不是啥坏事,比方软件中某个中央有 bug 或者更糟心的,架构某处存在缺点。  开发古代软件是一项高度简单、波及多职能及高度合作的过程。例如,专一于构建 web 端相应式 UI 的开发人员可能不肯定晓得如何配置为应用程序提供服务的 K8s 集群。现实状况下,该开发人员会专一于构建 UI 并放弃较低的内部认知累赘,而配置 K8s 机群会扩散对外围工作的注意力。对于该开发人员来说,K8s 是一个暗藏在形象层下的施行细节,与构建 UI 并没有间接关联。所以当每个人能够专一于本人的业余畛域时,开发团队的价值就能施展的最大。团队中的每个人都能够疏忽与手头工作不相干的事件时,相应的内部认知累赘就会很低。  DevOps 的认知累赘只管 DevOps 旨在进步软件开发效率,但 DevOps 工程师常常面临大量艰巨的工作,这些工作减少了他们的认知工作量。让咱们来看一些常见的例子。  首先,DevOps 工程师常常须要为新的软件我的项目设计新的流程,例如继续集成和继续交付(CI/CD)流程。DevOps 工程师可能还须要启动开发环境的基础设施,同时确保与生产环境的兼容性。这波及治理 Docker 文件、Helm 图表和 Terraform 代码,随着我的项目的倒退,这些文件须要定期维护和反对。CI/CD 管道也须要构建,只管工程师能够从以前的我的项目中获取某些局部,但新我的项目的新测试或构建要求会减少额定的复杂性。  现有流程必须扩充或放大以满足以后需要。这些流程包含扩大基础设施以满足新的解决或存储要求,以及批改为一直壮大的小型工程师团队设计的现有工作流程。  DevOps 工程师还治理软件工程生命周期许多方面的所有权。这包含在外部代码库和基础设施之上治理第三方工具和产品。其余开发人员还须要进行代码审查和会议来探讨须要业余 DevOps 常识的潜在解决方案选项。此外,DevOps 工程师必须确保零碎正确记录日志,并且能够收集和剖析指标。把握不同软件应用程序的性能对于确保它们顺利运行至关重要。它还能够帮忙工程师理解须要扩大的潜在畛域。  除了满足服务级别协定 (SLA) 和其余外部业务指标之外,所有这些都给 DevOps 从业者带来了微小的认知压力。每个工作和流程都会产生 DevOps 从业者必须解决的额定开销,通常会从他们的翻新和优化的次要指标中打消资源。  随着认知累赘的减少,相干的复杂性和压力也会减少,导致倦怠、谬误的减少。这会显著升高团队生产力,并最终克制翻新。  平台工程无效划分复杂性平台工程的存在就是为了提供多职能团队独特解决同一软件我的项目所需的形象。平台将软件运行在施行细节上的基础架构提供给开发人员,而在此基础架构上运行的软件也能同时成为经营团队的施行细节。平台工程无效缩小了日常工作的认知负荷,开发人员在平台中能够以自助服务的形式应用资源,打消了因为必须解决的流程(例如工单零碎)而导致的额定认知负荷。  平台工程的外围之一就是无效划分复杂性。企业组织中每个团队都有本人的职能畛域,该团队中的成员善于解决该畛域中的简单问题,于此同时其他人能够平安地疏忽这些畛域。每个人都依据独特的形象和对信息组合在一起的了解来解决施行细节。  举个例子,对于开发团队和经营团队来说,架构是一个共享协定,整个零碎须要运行能力使客户称心。这两个团队都应用形象:容器是在各种零碎上运行的单元,数据库等资源可用于依据须要存储数据。而施行细节依据职责有所辨别,对于经营团队的成员来说,施行细节包含网络、集群中的 Pod 策略和治理数据库实例。开发人员对施行细节就是要解决的业务问题。在整个我的项目中,平台工程是每个人实现其施行细节而进行沟通的路径和形式。  将平台工程纳入开发与 DevOps 中在这一部分,咱们将联合一个用例来阐明平台工程如何升高 DevOps 和开发人员的认知累赘并改良工作流程。  ...

July 5, 2023 · 1 min · jiezi

关于devops:从腾讯TEG-CDC解散聊技术中台价值和建设

近日一则腾讯TEG CDC整个部门遣散的音讯在很多群里炸了锅,有的唱衰互联网行业,有的豪言壮语,还有的甩锅到 AGI 的倒退。总体上来说,这个事件确实曾经产生了,我想从组织架构和整体效力这两方面来剖析下这次组织变动。 腾讯TEG CDC遣散6月28日,网传腾讯TEG CDC整体遣散,人员波及设计师、开发人员等,数百人规模。CDC是腾讯技术工程事业群TEG上司的一个中台化的设计反对部门,全称“腾讯用户钻研与体验设计部”,2003年开始组建,CDC的初创成员唐沐、陈妍。CDC 负责了腾讯成立以来许多重要产品的体验设计:如QQ、QQ空间、QQ游戏、RTX、QQ电脑管家、QQ浏览器、QQ音乐、腾讯视频、腾讯地图、QQ拼音、SOSO、拍拍等等。多年来,CDC造就了上千名用户体验相干从业人员,当初,他们在多个行业、企业及岗位上担起重任。 聊聊中台部门的意义和价值中台是一种体系/生态/方法论,解决顶层畛域下各业务子域的高效协同和资源复用问题。中台源于何处未知,的确最早在阿里大中台小前台的策略下流行起来的,然而起初阿里又被动突破了中台,把技术下沉到了业务,这是后话。目前支流的中台定义和分类有如下四种: 数据中台:通过数据技术,对海量数据进行采集、计算、存储、加工,同时统一标准和口径。技术中台:提供技术重用组件能力,技术撑持能力,帮忙解决基础设施,解决根底技术平台的复用。如微服务框架、DevOps平台、容器、DB等。智能中台:提供共享算法能力,帮忙提供更加个性化的服务业务中台:或称为利用中台,提供重用服务,例如用户核心、订单核心、营销之类的开箱即用、可重用的能力。中台建设初衷在于提效其实,中台的想法在公司效率为王的期间是很好的。比方一款产品波及A和B两个团队,A团队倒退迅速但资源无限只有5名设计师,B团队需要稳固工作量小但有10名设计师。 存在的问题: 公司倒退初期招聘不到足够多的特地有能力的资深员工不同业务倒退速度有别,资源不平衡业务倒退快,都急需反对设计规范性差,两个部门两种格调,难以协同解决办法: 把15名设计师独立成一个团队,由资深成员率领和领导资深设计师制订产品标准和设计师反对打算其它高级设计师依照标准工作,对多个产品进行反对,资深设计师进行把关资源有余时,依照产品重要水平和工夫节点等排优先级分配资源这样做很大水平上解决了设计团队能力的问题,工作品质问题,也满足了业务倒退的要求,公司整体效力失去了很大的进步。然而这种中台实际上是一种资源型中台,作为一个资源池,次要提供人力输入到业务线,和下面的各种中台还是有很大不同。 大而僵化的中台整体效力低随着资源型中台部门变大,逐步的固化和僵化,对业务的价值贡献度也在升高。 首先不深刻跟进业务部门需要的高级设计师,会被业务认为不了解业务,下里巴人,落不了地其次资源池构造的设计部门,谁都去申请资源,申请更多的资源,甚至超出本人须要的资源。没有外部老本结算,设计师和业务单方也简直都不思考老本,整体效力低。最初设计排期成为矛盾点。业务心愿大干快上,踩着点一步步往前走,然而设计排期有本人的排期,单方节奏不统一,引起矛盾。慢慢地业务方更违心应用大量的 HC 去招聘一些有教训的资深设计师,依照公司 CDC 的标准专门反对本人的业务。既满足了本人的需要,也解决了排期的问题,但长此以往 CDC的存在价值就更低。 资源型中台整体上资源型中台的倒退都会经验下面的过程,始于提效,终于效力差。除了设计师部门,上面的一些资源型中台也有这个问题: 专职和某业务对接的SRE专职和某业务对接的QA服务某个业务的经营服务某个业务的客服服务于一线的PMO 资源型中台建设的越多,沟通老本就越高,对业务的通畅阻力就越大。每个团队都有本人的人力布局、资源排期和业务指标。当各个团队的业务指标和本人的业务方不统一的时候矛盾就会展示。业务FTO/业务负责人就常会在这方面收到牵绊。 赋能型中台下面说到的数据中台、技术中台、智能中台(算法中台)、业务中台,属于平台型、业务型,整体上来说通过屏蔽底层细节,建设平台和服务能力,撑持上游业务倒退。尽管这些业务中台建设之初有大量的老本投入,整体上还是提效的,免去了很多人从前端到后端,从下层到上层所有货色本人都要入手写一遍,赋能属性是在的。至于能给业务点上几点天才,这就要看建设方的功力和业务的诉求了。 本篇总结整体上,我比拟偏向于资源型中台打散下派业务线,赋能型中台放弃短小精干长期聚焦。不要把资源型中台做大的同时,也不要把赋能型中台做没。这样做,对于公司来说整体效力是最高的,老本也是最节约的。

July 3, 2023 · 1 min · jiezi

关于devops:AI-和-DevOps实现高效软件交付的完美组合

AI 时代,DevOps 与 AI 共价联合。AI 由业务需要驱动,进步软件品质,而 DevOps 则从整体晋升零碎性能。DevOps 团队能够应用 AI 来进行测试、开发、监控、加强和零碎公布。AI 可能无效地加强 DevOps 驱动流程,从开发人员的业务实用性和反对的角度来看,评估 AI 在 DevOps 中的重要性是十分必要的。  在本篇文章中,咱们将一起探讨 DevOps 如何利用 AI 实现业务上的加强与晋升。  DevOps 中存在的摩擦在 DevOps 实际中,摩擦可能源于软件开发和经营生命周期中的各种挑战和瓶颈。这里咱们将总结6个 DevOps 中常见的摩擦。  DevOps 中的一个次要摩擦就是开发和经营团队之间存在孤岛。孤岛团队通常有不同的指标、优先级和流程,导致沟通阻碍、合作提早以及实现独特指标的艰难。这种摩擦会妨碍开发和经营的无缝集成,影响软件交付的速度和品质。  此外,DevOps 中的手动流程,例如手动代码部署、环境设置和配置管理,同样会导致效率低下。手动工作耗时、容易出错,并且可能导致跨环境的不统一。这些过程会减慢开发周期,减少人为谬误的可能性,并在企业实现高效牢靠的软件交付的路线上制作阻碍。各种 DevOps 实际中不足自动化会效率低下。当构建、测试和部署软件等重复性工作没有自动化时,会减少出错的机会,缩短公布过程,并从更具战略意义的流动中转移贵重的资源。自动化有余也会影响可扩展性,妨碍无效解决一直减少的工作负载的能力。  不充沛的反馈循环也会在 DevOps 中产生摩擦。当对代码更改、测试后果或部署的反馈提早时,会障碍疾速迭代和及时响应问题的能力。迟缓的反馈循环会妨碍缺点的检测,限度继续集成的有效性,并影响整个开发周期。对软件系统的性能、健康状况和用户体验的可见性有余会在 DevOps 中造成摩擦。如果没有对系统指标、日志和应用程序性能的全面监控和弱小的可见性,辨认问题、解决问题以及被动响应潜在瓶颈或故障就变得很艰难。无限的可见性会导致停机工夫缩短、系统可靠性升高以及保护服务水平协定困难重重。当事件响应和治理流程定义不明确或不足自动化时,就会在 DevOps 中引入摩擦。迟缓的事件检测、低效的沟通和手动事件处理会缩短解决工夫,影响零碎可用性、客户满意度和 DevOps 团队的整体效率。  AI 时代下的 DevOpsDevOps 和 AI 在很多方面都十分匹配。DevOps 须要自动化能力尽可能无效,而 AI 是解决重复性流动的自然选择。当咱们盘点 DevOps 团队软件公布提早的最常见起因是什么时,答复提到了手动、耗时、费劲且可能容易出错的流动,例如软件测试、代码审查、平安测试和代码开发。由此可见 AI 可能对许多团队简化这些程序至关重要。  应用 AI 缩小 DevOps 摩擦AI 能够通过提供简化流程和加强合作的自动化、智能和洞察力,从而缩小 DevOps 中的摩擦。 自动化流程:AI 能够自动化手动和重复性工作,例如环境设置、配置管理和部署流程。通过利用 AI 反对的工具和平台,DevOps 团队能够放慢工作流程,缩小人为谬误,并开释资源用于更具战略意义的流动。继续反馈和测试:AI 通过自动化代码剖析、测试用例生成和质量保证来实现继续集成和测试。AI 算法剖析代码存储库、辨认潜在问题并提供可操作的倡议。这通过进步代码品质、减少测试覆盖率和启用更快的反馈循环来缩小摩擦。智能监控和警报:AI 监控工具能够剖析来自日志、指标和用户行为的大量数据。AI 算法检测异样、预测性能问题并触发智能警报。这进步了对系统健康状况的可见性,缩小了均匀检测时间 (MTTD),并促成了更快的事件响应和解决。预测剖析和容量布局:AI 可能剖析历史应用模式、用户行为和工作负载趋势,以提供精确的容量布局和资源分配倡议。通过利用 AI 算法,DevOps 团队能够优化资源配置、预测峰值负载并防止适度配置和利用有余,从而缩小由可扩展性和资源管理问题引起的摩擦。智能事件治理:AI 能够主动进行事件检测、分类和解决。AI算法能够剖析事件数据、识别模式并倡议适当的补救措施。AI 驱动的聊天机器人和虚构助手能够帮助事件报告和响应,缩小响应工夫,最大限度地缩小停机工夫,并进步事件管理效率。 通过利用 AI 在自动化、数据分析和智能决策方面的能力,企业能够缩小 DevOps 中的摩擦。AI 能够更快、更精确地执行工作,进步可见性,加强合作,并使团队可能做出数据驱动的决策,从而实现更顺畅的工作流程、更高的效率和减速的软件交付。  ...

June 30, 2023 · 1 min · jiezi

关于devops:亚马逊实践-构建可持续发展的架构模型

可继续倒退概念源于对系统性文化危机和世界问题的迷信和社会意识形态钻研。世界级的提高学术社群和政治精英在二十世纪末就意识到了这些问题的存在。他们将行将到来的二十一世纪视为充斥不确定性、寰球劫难过程逐渐降级的时代。可继续倒退对多个畛域产生影响,目前已成为各国家、组织的战略重点。 亚马逊云科技开发者社区为开发者们提供寰球的开发技术资源。这里有技术文档、开发案例、技术专栏、培训视频、流动与比赛等。帮忙中国开发者对接世界最前沿技术,观点,和我的项目,并将中国优良开发者或技术举荐给寰球云社区。如果你还没有关注/珍藏,看到这里请肯定不要匆匆划过,点这里让它成为你的技术宝库!作为现代文明的一种经济政策理念和策略,可继续倒退的指标在于推动人类进入寰球动态平衡和有机增长的状态,而接下来的十年企业和组织正在开启新的可持续性倒退转型。 埃森哲最近的一项钻研示意,企业和业务的可持续性倒退转型在数字化和可继续化双重的交叉点上,新的价值正在日益被发现,数字化转型定义了过来十年的商业格局。将来十年的商业改革将由可继续倒退转型来定义。报告还指出,在可持续性指标的驱动下,在数字技术的反对下, “双转型”企业将会酝酿出基于生态系统的新商业模式,这种“双转型”的公司比其余公司更有可能在将来体现出强劲的劣势。有了数字化和可继续倒退化增长的双引擎,他们超过同行的可能性要高出 2.5 倍。 然而在可持续性带来业务增长的新趋势下,要实现可持续性转型也将面对新的挑战。 如何甄别碳排放热点?如何在经营中缩小能源和水的应用?如何翻新,如何更快实现可继续倒退转型?如何单干,如何实现共赢?在过来的十年外面,亚马逊云科技始终都致力于帮忙企业和开发者实现数字化转型,包含如何应用云技术帮忙企业进步经营中资源利用率;如何通过云基础架构、容器、DevOps 进行业务的翻新和敏捷性;将来的十年,亚马逊云科技将帮忙开发者和企业开始新的可继续倒退转型。让开发者能够应用雷同的工具更专一于可持续性工作,并通过最佳实际和整体基础架构,帮忙你应答在可继续倒退转型过程中的新挑战。 亚马逊的可持续性倒退之路如果你曾经开始应用云,如果你的工作负载曾经从数据中心迁徙到了亚马逊云科技的基础架构上,那么祝贺!你曾经跟亚马逊一起在可持续性倒退的这条路线上迈出了十分要害的一步,并实现了能源节俭的 80%。 咱们认为“上云”是企业节能减排的一个重要技术手段。为了实现可继续倒退的指标,亚马逊在寰球对本身业务波及的所有碳脚印进行了分类,通过应用亚马逊云科技的云服务,并联合 LCA(生命周期评估),构建了财务、运输、电力、包装、设施 5 个模型来实现碳脚印的计量,主动将简单和海量的物理和财务数据转换为特定业务流动的碳排放测量数据。而后,亚马逊在寰球应用这些计算的后果收集公司范畴内不同业务的碳脚印,确定不同业务的最大排放源,再根据不同类型的碳脚印制订有针对性的减排布局。利用这样的教训,亚马逊云科技正在帮忙寰球的企业和机构通过亚马逊云科技的服务在温室气体排放范畴全方位缩小碳脚印。 除了云基础架构带来的节能减排, 咱们也将本人的具体实际转化成云服务和云解决方案帮忙开发者独特实现可继续倒退转型。开发者肯定对亚马逊云科技平安/合规责任共担模型肯定不会生疏,平安责任共担模型能够帮忙开发者加重经营累赘同时提供灵活性和自控能力。咱们能够将这种责任共担的模型和概念同样利用于可继续倒退。 亚马逊云科技负责云的可继续倒退,包含:设计建筑物、房间、服务器,并负责从建造到回收的全过程。亚马逊云科技购买能源,并确保能源和其余资源(如冷却用的水)失去无效利用。最初,亚马逊云科技的服务团队运行治理服务并优化它们以实现可继续发展性。 而开发者负责云上的可持续性倒退,具体的责任是:做出架构决策,抉择和应用服务,确定哪些代码正在运行以及它的效率如何。 亚马逊云科技的可继续倒退责任共担模型 亚马逊云科技始终致力通过翻新的技术和我的项目,如采纳高性价比的解决芯片、利用 Amazon Sustainability Data Initiative(ASDI) 提供收费的卫星数据和气象模型拜访,移除地方 UPS 缩小能源转换,机架优化升高能源消耗,以及机房建设低碳化等等伎俩进行云的可持续性倒退转型。 云的可继续倒退 通过致力,咱们在云的可持续性倒退转型方面获得了成绩: 咱们在 2019 年与 216 个签署国独特携手,发动了《气象宣言》 https://www.theclimatepledge.com/?trk=cndc-detail 咱们将致力于在 2040 年实现净零碳排放,提前 10 年达成《巴黎协定》 https://unfccc.int/process-and-meetings/the-paris-agreement/t... 咱们正在以多种形式实现业务中的零碳排放。作为亚马逊云科技的开发者,您曾经受害于咱们为实现脱碳,以及在 2025 年实现 100% 应用可再生能源所做的致力,这比咱们最后的指标提前了五年。 451 Research 公布的 Carbon Reduction Opportunity of Moving to the Cloud for APAC 报告中能够看到,与承受考察的其余企业数据中心相比,在亚马逊云科技中运行应用程序, 碳脚印缩小 88%。 451 Researchhttps://451research.com/?trk=cndc-detail Carbon Reduction Opportunity of Moving to the Cloud for APAC https://d39w7f4ix9f5s9.cloudfront.net/e3/79/42bf75c94c279c67d...构建可继续倒退的架构模型如果构建一个可持续性倒退的这样一个模型,首先你须要制订一个正当的衡量标准。 ...

June 28, 2023 · 1 min · jiezi

关于devops:DevOps|中式土味OKR与绩效考核落地与实践

昨天一个小伙伴和我探讨了一下OKR和绩效治理,所以这次想简单明了地说下在中国怎么做比拟适合,很多高大上的实践无奈落地也是海市蜃楼。 首先说一些,我集体的了解 道德品质和能力素质决定了一个人的职位行为职位行为决定了业务后果不同级别/工作性质的人员,绩效考核应该有不同权重组合团队管理者的绩效不得高于团队的绩效 在组织层级中,基层一线小伙伴岂但要看功绩,还要看苦劳,而职级越高则越是要看业务后果。到管理层这个级别,这个时候苦劳意义曾经不大。因为对于基层一线小伙伴来说,有些功绩(业务后果),不是说本身具备了道德品质和能力素质就能拿到的。功绩和苦劳并重,这也是对基层一线小伙伴的一种爱护,因为很多时候基层一线小伙伴只是执行者,无奈决策,不能因为事件没做成,就一点收成也没有。 例子1:小伙子辛辛苦苦干一年,快要出活的时候,业务调整,我的项目不做了。这个时候你说小伙子绩效不好,这是不太适合的。 例子2: 管理层早8晚12点,咔咔的加班,后果一年多业务带黄了,这样的苦劳对公司没啥意义。 基层一线小伙伴看职业行为+业务后果中层管理者次要要看能力+业务后果管理层次要看业务后果OKR和绩效是一回事么?在一个零碎中评定?不是的,OKR有OKR零碎,绩效有专门的绩效零碎,采纳的360度评估考核,次要考核的是上下左右对你的工作认可,当然上占据的比重会大。 OKR是否关联绩效?关联。我的中式土味做法是把OKR间接转化成绩效考核中最重要的一部分,比方70%,同时加上一些企业文化、团队造就、技术分享,这样大家在实现OKR的同时,其实把本人绩效的次要考核局部也就实现了。 如果OKR不与绩效挂钩,就会产生你让我做的和最初考核我的不统一这个问题,这对一线员工来说,对积极性的影响比拟大。你让我干的我都干了,而后你拿一个素来没有跟我说的指标考核我?然而对非一线员工,其实360度考核影响得更大,因为曾经不能仅仅通过你每天的日常工作掂量你的奉献了。 OKR 与绩效考核啥关系?OKR的达成与否次要波及业务后果中能够量化的指标。有些不能量化的工作也能够是OKR的指标之一,然而如果想在绩效考核中体现,容易产生了解偏差。 OKR与绩效考核挂钩后会呈现设置OKR讨价还价?怎么解决?是的,OKR和绩效挂钩后会呈现这个问题。为了拿到好绩效,OKR都不会设置成「踮着脚可能到的指标」,少数会设置成「正好能实现」,这个时候在和团队每个人去聊的时候,还是冀望他们能设置的高一点。至多他们设置的高一点,在我这里印象分进步不少。 OKR的设定是自上而下,从上到下一层层去设置。下级设定实现 10 个性能,那么上级9集体的团队就要能至多实现 10 个性能,还要有其余奉献;如果9集体每个人设置实现1个性能,那么TL /团队的指标就是完不成的。团队每个人的指标要能无力撑持 TL 也就是团队整体的指标,如果没有拆解上来,那么就是 TL 的问题,也就是团队的问题。O 肯定要拆解上来,否则更大老板的 O 就完不成了。当然OKR也不是变化无穷,是能够依据理论状况更新的。 非一线员工, 是指Team Lead 对吧?至多是 Team Lead 这个级别。因为他们的大部分产出应该通过团队达成产出,与上下左右的合作,甚至是对公司业务达成的影响,而不仅仅是集体做了哪些事件。 TL的集体绩效是会参考OKR达成率和团队的业绩对吧?那团队业绩这块有做量化指标掂量吗?你能够认为团队业绩就是 TL 的集体业绩。因为你不这样认为也不行,团队绩效好的时候, TL本人也会把团队所有的绩效算到本人头上;团队绩效坏的时候,TL本人会把团队绩效放到其他人身上去。为了防止这两种状况,画约等号,甚至是等号是做好的方法。也能够激励 TL 率领团队拿到一个比拟好的团队绩效。 而他集体的OKR就是团队业绩中「事」局部做得好坏的最大考量指标,联合我下面说的360度,就是 TL 的集体绩效。也就是说 TL 集体绩效= 团队绩效 > TL 集体OKR + 360考评+ 企业文化+ 治理能力 很多员工最恨的就是团队绩效很差,然而 TL 拿了超出团队绩效体现的高绩效。 指标治理和绩效治理的问题,不论是KPI还是OKR,经典难题?国内绩效治理和考核波及到因素比拟多 1)中国「人际关系」「体面」在作怪,360度评估不牢靠;2)在中国工作压力大,很多时候是既要有OKR 又要有 KPI,还要有企业文化等软性指标。3)中国企业倒退快,变动也快,国外很多的实际落地都要通过改进。4)年终奖在员工薪资中占比过大,每个人都要争取高绩效;而在外企,大家绝对躺平一些,OKR/绩效考核尽管有差别,然而大家拿到手的差距没那么大。

June 20, 2023 · 1 min · jiezi

关于devops:龙智携手Atlassian亮相DevOps国际峰会释放团队潜力以协作挑战不可能

2023年6月29日到30日,龙智将亮相DevOps国内峰会 · 北京站213展位。本次参展,咱们将出现Atlassian ITSM、DevOps以及工作治理三大解决方案,帮忙您开释团队的力量,将不可能变成可能。 龙智自主开发多款Atlassian插件,满足外乡业务场景特地需要自2015年与Atlassian成为合作伙伴以来,龙智已与其携手在中国市场走过近10年。龙智是Atlassian最高级别(白金)合作伙伴、大中华区首家云业余搭档。到目前为止,领有两名Atlassian认证专家以及21个Atlassian认证集体。 不仅如此,龙智也积极参与Atlassian生态圈的建设。截至目前,咱们已在Atlassian插件市场上架了20款自研插件,其中包含Jira组织机构插件、Jira工时治理插件、Confluence到期日揭示插件、Confluence水印插件、Confluence周报插件、Confluence便当工具,以及集成飞书、企业微信和钉钉的插件等。龙智自研Atlassian系列插件已销往美国、英国、意大利、法国、匈牙利、土耳其等二十个多国家和地区。 龙智Atlassian ITSM, DevOps及工作治理解决方案:开释团队力量,将不可能变成可能本次DevOps国内峰会,龙智与Atlassian再度携手,带来ITSM, DevOps及工作治理解决方案,实用于所有类型的工作。 基于Jira Service Management的ITSM解决方案:解锁高速团队 古代IT经营领导者如何解脱传统思维模式,并为企业的将来倒退提供能源?龙智Atlassian ITSM解决方案专为打造古代、高速的IT服务治理团队而来,提供了一种弱小、灵便且便于合作的形式,帮忙您交付合乎员工、客户冀望的卓越服务。 并且,Atlassian的ITSM解决方案屡次取得国内权威机构的认可,在Gartner 2022年《IT服务管理工具魔力象限》中,Atlassian ITSM被评为 “领导者”,Forrester Wave也将Atlassian评为ESM(企业服务治理)的“领导者”。 Atlassian为高速ITSM提供了一个平台——Jira Service Management,借助其申请、事件、事务、变更和配置管理等性能,能够疾速将研发、IT经营和业务团队联合在一起,帮忙团队在交付、经营和反对等方面提供卓越的服务体验。 以Jira为外围的开放式DevOps解决方案:减速软件开发 问一百个开发团队他们用什么工具来公布软件,您会失去一百个不同的答案——每个团队都是不同的,每个我的项目都是独特的,工具的倒退速度也十分快。龙智Atlassian DevOps解决方案让工具的抉择不再是一种斗争,让工具的配置、应用和保护不再是一种负累,从而让团队专一为客户提供价值。 龙智Atlassian DevOps解决方案以Atlassian最为出名的项目管理软件Jira为外围,秉承凋谢的理念,放眼寰球,帮忙您集成团队所需的、喜爱的工具,从打算、开发、代码剖析、测试、继续集成/继续部署,到交付、经营以及平安,搭建残缺的工具链,赋能世界级的开发团队。 集成Confluence等工具的工作治理解决方案:凝聚团队智慧 大型、简单的我的项目胜利的秘诀就在于项目管理。龙智Atlassian工作治理解决方案可能满足您所有的工作治理需要,让您的合作形式标新立异,却又轻松高效。工作治理的根底是企业wiki与文档协同软件——Confluence。它为团队搭建了对立的信息平台,帮忙团队成员相互合作,实现信息共享。基于常识分享,再集成项目管理、数字团队合作以及跟踪目标与协调状况等性能,工作治理解决方案凝聚团队的智慧和力量,使决策更理智、更迅速。 以上三大解决方案为企业发明出连贯、协同且高效的软件开发,帮忙其充沛开释团队潜能,让团队合作迈入一个新时代。 欢送返回213龙智展位,业界前沿资讯、行业报告和惊喜抽奖等你来!咱们热诚邀请您光临213展位,与龙智专家进行互动与交换,理解DevSecOps、ITSM及工作治理的最新趋势及倒退。咱们将于现场为您提供丰盛的报告、资讯以及最佳实际案例,还有精美礼品与抽奖流动,让您不虚此行。

June 19, 2023 · 1 min · jiezi

关于devops:模糊测试不模糊高效发掘未知漏洞与-0day-攻击

近日,在「DevSecOps软件平安开发实际」课程上,极狐(GitLab) 高级测试工程师衡韬、极狐(GitLab) 高级后端开发工程师田鲁,分享了含糊测试的概念、必要性和在极狐GitLab 上的实际。 以下内容整顿自本次直播,你也能够点击观看视频回放。Enjoy~ 随着网络应用的遍及,人们越来越关注软件安全性、稳定性和软件品质问题。而软件系统也越来越简单,即便通过认真测试的软件也时有 Bug 逃逸。为了解决这一问题,含糊测试作为一种高效测试方法,被宽泛关注和钻研。 什么是含糊测试?概念含糊测试(Fuzzing Test)一种黑盒/灰盒软件测试技术,通过提供随机输出来检测程序中的谬误、破绽等,帮忙发现程序中的边界条件谬误、内存透露、缓冲区溢出等潜在问题,验证软件性能的正确性、稳定性与健壮性,进而进步零碎安全性。 API 含糊测试是含糊测试的典型利用。在 API 成为古代软件架构的根底与要害的背景下,作为评估 API 安全性无力伎俩的 API 含糊测试的重要性显而易见。 常见测试方法论这里延展分享软件测试中罕用的测试方法论:个别分为有黑盒测试、白盒测试和灰盒测试。它们的区别在于测试人员对系统内部结构的理解水平: 黑盒测试:只根据需要与性能进行测试,测试人员不须要理解内部结构与实现;白盒测试:根据构造与代码进行测试,测试人员须要齐全理解或管制内部结构;灰盒测试:介于黑白盒测试之间,测试人员对局部内部结构有所理解,测试既思考输入与性能,也关注测试覆盖率。而含糊测试的测试用例与数据是随机生成的,不依赖于软件内部结构与实现,测试人员无需齐全理解软件外部逻辑。因而,含糊测试属于黑盒或者灰盒测试,且即便不相熟代码自身的测试人员也能够承当相应工作。 不同角色的人进行含糊测试时有何不同?不同角色的人进行含糊测试时,视角和关注点也不同,举个例子: 开发同学更关注代码逻辑,通常依据软件外部的实现逻辑及其可能的破绽与问题点来设计含糊测试计划。如下图,开发同学有可能间接针对代码或接口进行测试,而疏忽内部依赖或上下文。 测试同学更关注业务逻辑,通常依据软件的业务逻辑、内部接口与用户场景来设计含糊测试计划。如下图,测试同学会生成实在仓库,设置多个参数值,提交蕴含文件变更的 commit 等,尽量更贴近理论用户操作。 平安工程师则更关注危险,通常会设计含糊测试计划来发现各种潜在的安全漏洞,更关注危害重大的问题。 了解各个测试角色的劣势与局限,通过沟通合作来补救各自的有余,精心设计全面而有针对性的测试计划,是施展含糊测试甚至任何测试技术最大效用的因素之一。 含糊测试 VS 传统测试含糊测试次要能够分为以下 6 个步骤: 辨认指标零碎;辨认输出;生成含糊数据;应用含糊数据执行测试;监控零碎行为;后果记录与剖析。其中 1-5 步与传统测试工作流程高度类似度,在步骤 6:后果记录与剖析上,传统测试和含糊测试是齐全不同的: 传统测试的后果剖析,关注预期后果,确认是否实现需求。例如测试是否失常登录零碎,失去的后果是失常登录或不能失常登录。含糊测试的后果剖析,更关注意外后果与异样行为,偏重发现未知破绽。在上述例子中,含糊测试则是寻找和剖析让登录零碎解体的起因。换句话说,含糊测试更关注被测系统的稳定性和健壮性,不在意零碎的业务行为正确性。另外一个不同之处在于,含糊测试难以用人工染指。次要因为: 含糊测试产生海量随机测试用例,使得人工判断与染指每个用例变得不事实;含糊测试产生的大量测试后果须要判断预期与异样,人工难以完成,须要依附高度自动化的算法来剖析分类。为什么要做 API 含糊测试?API 已成为基础架构古代软件系统基于微服务架构,大量应用 API 进行服务调用与集成。API 的安全性间接决定整体零碎的安全性,所以 API 含糊测试是评估零碎安全性的要害一环。 疾速公布需要进步很多企业都在应用麻利开发,要求更短的更新周期和更高的公布频率。这减少了因为忽略或考虑不周导致安全漏洞的概率。 而麻利规范下,每一个迭代都是一个可用的产品,必须关注安全性;同时,无论是安全性缺点抑或可用性缺点,越早修复,老本越低。 因而,利用 API 含糊测试进行继续监测是一个很好的抉择,确保疾速迭代不会引入高危破绽。 人工不可能齐全笼罩 API 输出如前文所言,含糊测试通过提供随机输出来检测程序中的谬误、破绽等。而 API 输出域往往过于宏大,人工很难思考每一种输出的安全性。 API 含糊测试能够随机产生海量测试数据来尽可能笼罩所有输出场景,测验 API 的健壮性。 API 含糊测试在极狐GitLab 上的实际在开发过程中利用含糊测试的好处不言而喻,能够在 QA同学进行测试之前,极早发现问题并解决问题,缩小单方沟通老本和工夫。 反对格局在极狐GitLab上,API 含糊测试目前反对以下几种格局: ...

June 16, 2023 · 2 min · jiezi

关于devops:k8s-docker-基于-kubeadm-多节点集群部署

k8s + docker 基于 kubeadm 多节点集群部署博客文章地址:https://blog.taoluyuan.com/posts/install-k8s/ 各个节点环境筹备[环境筹备] 这章的操作都要在两台机器上别离执行,我筹备了两台机器,如下: 一台master,一台node主机1(master) ip:192.168.31.122,主机2 192.168.31.166 1. docker 装置如曾经装置好docker 可跳过docker 官网装置 https://docs.docker.com/engine/install/ubuntu/ 有点慢清华大学 镜像装置办法 https://mirrors.tuna.tsinghua.edu.cn/help/docker-ce/ 装置依赖 sudo apt-get install ca-certificates curl gnupgsudo install -m 0755 -d /etc/apt/keyringssudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpgecho \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://mirrors.tuna.tsinghua.edu.cn/docker-ce/linux/ubuntu \ "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null装置 docker-ce sudo apt-get updatesudo apt-get install docker-cedocker组授予用户根级权限,让以后登陆也能够应用docker sudo groupadd dockersudo usermod -aG docker $USERnewgrp docker镜像加速器 ...

June 10, 2023 · 2 min · jiezi

关于devops:GitOps-实践之渐进式发布

**本文作者:陈钧桐腾讯云 CODING DevOps 高级解决方案架构师**,从事多年技术布道工作,对于云原生时代下企业数字化转型、IT 与 DevOps 建设、价值流体系搭建等有丰盛的教训,曾为多家大型企业提供征询、解决方案以及内训服务。既关注工程师视角的云原生开发建设与最佳实际落地,也关注管理者视角的过程治理与研发效力晋升。 本文基于陈钧桐老师在 2023 年中国 DevOps 社区峰会·武汉站上的演讲内容进行创作,其在此次峰会中被评为“十佳讲师”,并被社区认可为优良的常识分享者。 导语随着云计算和微服务架构的遍及,软件开发和运维的环境变得越来越简单,在咱们谋求开发和交付的最佳实际时,GitOps 的概念应运而生,并迅速取得了宽泛的认可。在许多无效的 GitOps 实际中,渐进式公布作为一种危险管理策略,扮演着重要的角色。它容许咱们逐渐公布新的服务版本,可能在保证系统稳固的同时,尽快地将新性能或修复带到生产环境。具体实现的策略有多种,包含滚动降级、蓝绿部署、灰度部署、金丝雀公布,以及 A/B 测试等。 在这篇文章中,咱们将探讨如何将 GitOps 和渐进式公布联合起来,以实现在云原生环境中的高效、牢靠和平安的服务部署。咱们将会比拟剖析不同的渐进式公布策略,介绍支流的云原生工具,以及应用 CODING 自研的云原生利用治理平台 Orbit 进行优雅实现。咱们心愿这篇文章能为那些心愿在本人的软件开发流程中引入 GitOps 和渐进式公布的读者提供有价值的信息和启发。 注释 GitOps 是由 Alexis Richardson 在 2017 年首次提出的,该模型主张将 Git 作为"繁多事实起源"(Single Source of Truth)来治理和同步开发和生产环境,而不是应用传统的基础设施治理和部署形式。这个思维提出后,引发了一场对云原生部署和运维模式的探讨和反思。 GitOps 的概念在 2018 年开始被更多的组织和云服务提供商承受和利用,它们都开始摸索如何将 GitOps 集成到本人的产品和服务中。例如,亚马逊、谷歌和微软等云服务提供商都在他们的 Kubernetes 服务中集成了 GitOps 工具。 到了 2020 年,为了进一步推广 GitOps 理念和实际,云原生计算基金会(CNCF)发表成立了 GitOps 工作组。这个工作组由多家云服务提供商和软件公司组成,他们一起制订了一套标准化的 GitOps 最佳实际和准则。 2021 年,GitOps 成熟度模型诞生,这是 GitOps 工作组和社区共同努力的后果。该模型提供了一种量化和评估 GitOps 施行的办法,从而帮忙组织更好地了解和施行 GitOps。 ...

June 7, 2023 · 4 min · jiezi

关于devops:DevOps-研发效能和PMO如何合作共赢

项目经理(PMO)对于大组织、跨团队高效协同有着不可代替的作用。跳出组织架构的解放,横向推动公司级别的大我的项目向前推动,跟进停顿和拿到后果,PMO的小伙伴有着独特的劣势。 我之前写过小团队如何高效合作的一篇文章《 高效能麻利交付团队反思:个性团队(FeatureTeam)+Scrum》,还写过一篇对于研发效力团队组织架构的文章《互联网公司研发效力/工程效率团队建设和布局》。这两篇文章对于我的项目推动、研发效力团队和PMO团队如何合作有过一些介绍,本文将在这两篇的根底上做一些补充。 本文重点探讨研发效力团队和 PMO 团队如何团结一致,单干共赢。 项目经理(PMO)的诉求和指标首先咱们须要理解项目经理(PMO)的具体诉求和指标,以便咱们可能更好地了解和反对他们的要求和冀望,并同时从研发效力的角度登程,给出业余的意见和倡议,表白咱们的想法和计划,一起来探讨如何更好地为业务提供撑持,确保各业务线在工程能力与效率上能的确有所晋升。 研发效力团队更关注进步产研合作效率、过程改良、产品质量进步和平台用户体验;项目经理(PMO)更关注资源投入、我的项目停顿和业务指标达成。了解这一差别能够防止矛盾,也能更好地找到单干的契合点。 如果一味地进行过程改良和产品质量,漠视了业务指标的达成,造成业务无奈按期保质保量的交付。这就成了流程改良的背面例子。 研发效力给PMO提供工具撑持既然项目经理(PMO)更关注资源投入、我的项目停顿和业务指标,咱们研发效力团队能够在这些方面给予工具反对。比方我的项目资源的统计,我的项目停顿的可视化,业务指标的细分和跟进等等,这些都能够靠研发效力平台来主动统计与展现,不便PMO的小伙伴失去这些数据。 PMO能够给研发效力团队反馈当产研的小伙伴和PMO同学都应用咱们的研发效力平台时,咱们须要来自用户的反馈,而作为与业务肩并肩战斗的小伙伴,PMO当然有发言权。而且PMO在工具抉择、流程改良和品质晋升上有十分高的话语权。咱们能够与PMO的小伙伴一起把这些工作做好。 如果研发效力团队闷头干活,闭门造车,做进去的平台很可能不是业务须要的,这样的例子亘古未有。平台团队在那里炫技,在那里挠头想出了一个好想法,后果业务方都不想看第二眼。 举个例子,比方很风行的 Infra as Code(IaC),很多人在宣扬这个事件,不论公司死活,团队大小都要上 IaC。我感觉把 IaC 裸露在他本来所在的边界内能够,比方ops team,然而千万不要影响上下游团队,让大家也都承受 IaC。小公司原本存活工夫就短,老板折腾无所谓;大公司分工合作,高效协同,如果强推某些看似「酷炫」理论对别人无用的货色,十分地遭抵制且危险。 研发效力和PMO相互合作研发效力和PMO都是独特反对业务,所以很多时候要通力协作,比方一起加入业务会议,一起收集反馈,独特施行流程改良等等。 PMO因为须要跟进资源、进度和后果,所以和业务方的治理团队有着宽泛的接触,能够带来一线产研小伙伴工作之外的诉求。而这些诉求对于研发效力团队的胜利有着重大的影响。然而这些诉求,也须要认真甄别,有时候就是某个大佬拍脑袋想出的货色,如果你不辨真伪不分好坏循序渐进去做,就会出问题。 比方一些+2+3的大佬,因为曾经无奈实时跟进N个我的项目的停顿,很难评估一线员工的产出,这时候就想通过代码量来分别一下。其实他本人也是晓得如果仅靠代码量难以无效分别,然而苦于没有其它数据。此时研发效力平台方就要好好地想一想是否要做这个需要,怎么做这个需要。 分享我的项目成绩和荣誉业务胜利才是真正的胜利。在研发效力团队的撑持和PMO 团队的反对下,只有业务获得最终的后果才是真正的胜利。没有后果的过程屁都不是。咱们要携手和业务方一起拿到后果,同时要独特分享我的项目的胜利与荣誉,这将有利于进步团队凝聚力,这也是对研发效力工作最好的认可和回馈。 举个例子,已经有个产品刚上线,前后端一起去团建了,其余的小伙伴还在公司咔咔的工作。干活的时候称兄道弟,刚上线就开始分角色分正式外包,这就有点太伤人了。 思考项目经理(PMO)对于大组织、跨团队高效协同有着不可代替的作用。然而这里有一点点的瑕疵就是 PMO 团队是否对最初的后果负责。依照鸡和猪开饭店的例子来说,鸡只出了几个鸡蛋,猪却要奉献一条腿。 我的其它文章高效能麻利交付团队反思:个性团队(FeatureTeam)+Scrum研发效力组织能力建设之个性团队FeatureTeam(上) 互联网公司研发效力/工程效率团队建设和布局DevOps|AGI : 智能时代研发效力平台新引擎(上)AI DevOps | ChatGPT 与研发效力、效率晋升(中)

June 5, 2023 · 1 min · jiezi

关于devops:平台工程是-DevOps-的未来

Gartner 预测到 2026 年时,将有 80% 的软件工程组织会建设平台团队DevOps 与平台工程DevOps 是一种文化和理念。平台工程,是咱们实现“谁构建、谁运行”的惟一形式。这是 DevOps 的外围初衷,也是起初企业级规模和云原生时代的实现根底。平台工程关注的不肯定是教你怎么用工具,而是构建起一套可能实现这种自我服务能力的平台。有了平台工程,外围软件工程部门才有机会取得自我服务能力。这种观点上的转变,决定咱们要把平台视为一种产品进行建设。 DevOps 最后的想法非常简单,根本指标就是打消开发人员和经营人员间的阻碍,促成单方合作。达成指标的办法根本就是做左移,实现“谁构建、谁运行”。当所有这些云原生趋势交融在一起之后,就有了云原生、Kubernets、容器化、基础设施即代码和 GitOps 等等,状况曾经齐全不同了。 为什么须要平台工程面对简单的工具链,开发者没必要成为全面的专家,相同,应该把底层基础设施的复杂性从开发者那里形象进去,为他们提供一条最佳门路,由开发者本人决定最适宜的上下文层级。 在企业中,平台工程的推动会遇到困难,特地是认知负荷相干的问题。首先,开发者手足无措从而一直向经营团队求助,最终经营团队成为业务瓶颈;亦或高级工程师会轻轻用本人的方法接管了经营工作,成为“影子经营”,并没有把全副的精力投入到编码当中。这两种形式会陷入恶性循环最终成为技术债权。因而,咱们倡议建立平台工程团队的角色、思考建设和应用工程平台。 什么样的团队须要工程平台如果团队中只有大概20 名工程师,而且不是每个人都相熟 helm、IaC、Terraform 或者 Kubernetes,PaaS 是不错的抉择 。 DevOps 的根本诉求“谁构建、谁运行”能够实现。但 PaaS 只能提供一条门路,只能通过简略设置反对绝对不那么简单的用例。 当企业从几十名开发者转变为成千盈百开发者时,平台有助于解决的痛点才开始真正呈现。痛点呈现了,摩擦呈现了,如果还没有任何平台,那须要口头起来了。如果曾经领有 PaaS 解决方案,无妨思考逐步过渡到自建的外部开发者平台,或者应用价值观雷同的、较为成熟的内部产品。 如何建设平台工程设立平台工程团队,平台工程团队的使命和愿景是构建、成就或引入一款产品,这款产品的客户就是开发者。 其次,平台工程团队要器重沟通能力。在跟开发人员交谈时,要强调的是如何缩短等待时间、改善开发体验。而在跟经营团队交换时,要通知他们如何加重压力并疾速解决工单。而在跟管理层沟通时,最重要的一点就是告知如何缩短产品上市工夫,并且可能升高经营老本。这个指标相似于给平台设定投资回报率。 开发者平台的指标是为工程师们提供相似于 PaaS 的应用体验和开发体验。但它基于更简单的标签和工具堆栈,搞清楚工具箱里到底有着怎么的技术组合。把整个栈接管过去,实现最初一英里的优化,通过微调为开发者构建起合适的最佳上下文门路。 平台工程不能成为开发团队的解放。一方面,须要通过标准化遍及升高认知和应用门槛,实现自服务。同时,还得确保开发者应用基础设施资源的形式跟平台规范要求相一致。这里要么采纳始终如一输入雷同的配置文件,进行动静配置管理,本质在于每次部署时都能动静生成配置文件,包含谁部署了什么、在哪里部署、输入了什么。动静配置管理还能在每次 Git 推送时执行策略和规范,在部署等环节之间建设束缚。如果没有明确思路且根底较薄、或不想投入非主营业务老本,能够评估抉择一款内部产品,其具备残缺的交互控制台、践行一套认同的方法论、最重要的是违心与客户放弃沟通、继续迭代,客户能够和产品一起走向平台工程终态。 平台工程产品化趋势在海内,开源社区十分火爆,存在不少开源工具如 Argo CD、Backstage,特地是围绕 Backstage 的插件体系十分丰盛,曾经呈现了上百种插件;也有平台编辑类产品 Humanitec, 服务于企业平台层中外部开发者平台的外围引擎,是平台工程、团队和组织中的解决方案之一。相比之下,国内的工具链绝对简单,为了晋升端到端的体验,通常须要一个整合层或平台层来更好地组合这些工具。而且在国内平台工程次要以代码和自我品牌为核心,比方腾讯云的 CODING Orbit 等产品。 以开发者视角为出发点,围绕着代码治理、项目管理、需要设计、缺点治理、测试治理和制品治理、继续集成、继续交付、利用治理/观测等外围个性构建。在这些平台中,代码和制品模式的流转更多地产生在不同的产品模块之间。每个产品外部都有十分丰盛的性能机制,这种商业软件的玩法是开源平台无奈做到的。国内外工具与平台最终是否依照平台工程的需要场景演进趋同?让咱们刮目相待。 欢送扫码增加 CODING 官网小助手 获取 2023 平台工程报告

June 2, 2023 · 1 min · jiezi

关于devops:1-行代码开启密钥检测给敏感数据加上防护锁

 近日,在「DevSecOps 软件平安开发实际」课程上,极狐(GitLab) 高级业余服务交付工程师韩飞、极狐(GitLab) 前端工程师任治桐,分享了密钥检测的背景、利用及解决,并演示了极狐GitLab 密钥检测性能,快用 1 行代码开启密钥检测性能,给敏感信息加上平安锁。 以下内容整顿自本次直播,你也能够点击观看视频回放或下载 PPT。Enjoy~ 在利用程序开发过程中,开发人员为了本地 debug 不便,会 hardcode 一些信息,比方连贯数据库的用户名、明码、连贯第三方 APP 的 token、certificate 等,如果在提交代码的时候没有及时删除这些信息,则非常容易造成敏感信息透露,带来被拖库、撞库等危险。 举个例子:某公司一名工程师无心中将与客户往来的邮件以及零碎登录信息(包含明码、密钥对和私钥)上传到公开的存储库上,黑客就应用公开的明码和密钥进入企业外部零碎,进行偷窃数据、公布非法信息等操作,给企业造成了重大经济损失,重大影响客户信赖与企业声誉。 相似的密钥信息透露案例不足为奇。有没有一种方法,可能在开发人员提交代码前,就提前发现代码中的密钥信息,躲避密钥泄露危险?密钥检测应运而生。 密钥检测常见做法企业进行密钥检测罕用的办法包含:自研检测工具、开源工具整合、第三方检测服务、混合应用等。这些办法都有其优劣势,例如: 自研检测工具:最大限度符合企业环境与需要,但须要投入大量人力与资源;开源工具整合:依赖开源工具的检测能力,须要自行保护与降级;第三方检测服务:能够疾速建设密钥检测能力,但须要承当服务费用,性能上也受制于服务提供商,可持续性低;混合应用:工具链简单,需投入资源进行治理与保护。极狐GitLab 密钥检测劣势极狐GitLab 认为密钥检测是 DevSecOps 的重要话题,与软件开发全生命周期中的每一个人非亲非故,最好的形式就是将密钥检测集成到 CI/CD 中,在开发人员提交代码时就同步进行检测,真正做到平安左移,继续监测。 一体化:简化治理难度与复杂度密钥检测作为七大 DevSecOps 性能之一,内置于极狐GitLab 中,无需繁琐的软件部署,实现扫描报告、配置、打算工作等对立界面治理,无需在多个软件系统之间切换,充沛简化治理难度与复杂度。 配置简略:一行代码,即可启用只需在极狐GitLab CI  配置文件中减少一行代码,即可将密钥扫描模板导入流水线,轻松启动密钥扫描,发现并修复我的项目的密钥平安问题。 笼罩全面:100 + 密钥扫描选项极狐GitLab 密钥检测蕴含 100 + 种规定集,笼罩密钥平安检测方方面面,包含是否泄露或重复使用,密钥抉择、长度、加密算法是否存在安全隐患等,帮忙用户发现在日常应用中容易疏忽的危险与破绽。 开源凋谢:每一行源代码公开可见极狐GitLab 作为开源软件,用户能够自在查看密钥检测性能的每一行代码,依据企业平安需要开发自定义和扩大默认性能。 并且,极狐GitLab 继续更新与改良密钥检测的规定与检测形式,以适应新的平安威逼与需要变动。用户能够随时查看更新的具体代码变更,取得更强的检测能力。 密钥检测「根底」应用形式如前文所言,极狐GitLab 可通过一行代码,启用密钥检测。这是最根底的应用办法,可疾速试用与评估密钥检测性能。 ➤ 导入 CI 模板 .gitlab-ci.yml 在极狐GitLab CI/CD 中导入密钥检测的 CI 模板,模板仅蕴含一条启动密钥检测的作业,导入后可立刻执行密钥扫描。 ➤ 主动增加密钥检测作业 在 CI/CD 流水线部署阶段,主动增加一条启动密钥检测作业,使每个流水线在部署前主动执行密钥扫描,造成继续检测机制,发现密钥平安问题及早修复。 ➤ 显示密钥检测报告 密钥检测作业实现后,在极狐GitLab 流水线界面展现扫描报告,阐明检测到的各个密钥中存在的平安问题以及修复倡议,辅助用户高效修复或更换不平安密钥。 ...

June 1, 2023 · 2 min · jiezi

关于devops:7-步提升私有化部署的极狐GitLab-实例安全等级

本文起源:about.gitlab.com作者:Ayoub Fandi 译者:极狐(GitLab) 市场部内容团队“系统安全水平取决于零碎最单薄的环节” 是一句十分易懂的谚语,好比平安防护的木桶效应。 如果攻击者找到了入侵办法,就会利用平安配置文件中的任何破绽。「强化」,即敞开未应用性能,并把对平安有影响的设置进行调整的过程,对于限度攻击面并缩小潜在攻打向量是十分重要的。 「强化」能够确保应用程序(比方极狐GitLab)尽可能的平安。指标很简略:保留高效工作所需性能的同时,将危险最小化。 领导准则以下列举的平安流动须要和其中的一项或者多项联合应用。能够尝试组合尽可能多的办法。 分层平安,纵深进攻分层平安背地的逻辑很简略:尽可能尝试将多种平安办法联合起来。例如,有两种形式实现平安,则应该实现两种,而非只实现一种。 举个例子,如果想保障服务拜访平安,可将简单明码、硬件拜访令牌及多因素认证联合起来。这种办法也被称为纵深进攻。 窃密 ≠ 平安“如果某些货色被暗藏,那么它会变得更平安”的想法,在现如今的信息安全世界里,是行不通的。 以后攻击者的扫描能力足够弱小,可能冲破紧密的平安防控。任何人都很容易对系统的凋谢端口进行扫描,例如将 SSH 的 22 端口批改为其余端口,诸如 Nmap 之类的网络工具就能够扫描进去。 缩小攻击面极狐GitLab/GitLab 蕴含泛滥组件、服务及依赖,提供弱小的产品性能。但领有的组件越多,攻击者的攻打入口就越多。所以牢记一个法令:禁用运行应用程序不须要的服务。如果有未应用性能,禁用相干服务将缩小潜在攻击面,更加平安。 7 步保障私有化部署实例平安让咱们通过简略 7 步,疾速强化私有化部署实例。这些速效措施是保障平安的重要开始。额定细节及进一步领导,可参考官网文档。 第一步:开启多因素认证管理员 → 设置 → 通用 → 登陆限度 确保勾选双重认证(Two-Factor authentication,2FA)选项。双因素宽限期的默认值是 48h,将其调整为一个更低的值,比方 8h。 确认勾选管理员模式。具备管理员拜访权限的用户,将须要额定的认证操作来执行治理工作。启用 2FA 后,将须要用户进行额定的 2FA 认证操作。 第二步:增强额定的注册查看管理员 → 设置 → 通用 → 注册限度 确保勾选启用注册性能。 在电子邮件确认设置下,确认开启高级设置。这将要求用户在容许拜访其帐户之前,在注册过程中验证其电子邮件地址。 如果强制执行其余身份验证技术,则 12 个字符的最小明码长度(字符数)默认设置是比拟适合的。可用的明码复杂度选项包含需蕴含数字、大小写字母及特殊字符。是否启用明码复杂度性能,取决于你公司外部的明码规范。 如果所有用户邮箱地址都位于繁多域名(比方 example.com ) 上面,可在注册限度里,将其增加到容许域名一栏中。这将阻止非此域名下的邮箱进行注册。 第三步:限度群组和我的项目可见性管理员 → 设置 → 通用 → 可见性和访问控制 对于新创建的我的项目和群组,其默认我的项目可见性和群组可见性都应该设置为公有。只有被赋予特定拜访权限的用户,能力拜访特定资源。如有必要或在创立新我的项目或组时,能够对此进行调整。 这可能确保默认模式平安,避免信息意外透露。 第四步:强化 SSH 设置管理员 → 设置 → 通用 → 可见性和访问控制 ...

May 31, 2023 · 1 min · jiezi

关于devops:通过-Github-workflows-CICD-自动化部署-Github-Pages-hugo-免费博客

通过 Github workflows CI/CD 自动化部署 Github Pages hugo 收费博客文章博客地址:https://blog.taoluyuan.com/posts/github-workflows/ Github Workflows 介绍GitHub Actions 介绍GitHub 文档:https://docs.github.com/zh/actions/learn-github-actions/understanding-github-actions官网介绍:GitHub Actions 是一种继续集成和继续交付 (CI/CD) 平台,可用于主动执行生成、测试和部署管道。 您能够创立工作流程来构建和测试存储库的每个拉取申请,或将合并的拉取申请部署到生产环境 流程及原理介绍本文次要介绍应用GitHub Actions 来实现自动化部署博客网站 ,动态网站生成应用的是Hugo,部署应用的是Github pages,并且应用自定义域名。本地写hugo-blog 博客,hugo-blog 是一个hugo的博客模板,应用hugo new site hugo-blog命令创立,能够在外面写markdown文件写好后推送到github hugo-blog 仓库,触发github actions ci/cd,执行hugo命令生成动态网站,并且推送到github-pages 仓库github-pages 仓库接管到推送后,会主动部署到github pages,公网能够通过 github pages 域名 拜访,也能够通过CNAME配置自定义域名拜访 Github Pages 介绍Github Pages 是一个动态网站托管服务,能够通过github pages 托管动态网站,并且能够通过自定义域名拜访创立github pages 仓库,仓库名必须是username.github.io格局,username是你的github用户名,仓库名必须是这个,否则无奈部署胜利 拜访地址就是 https://username.github.io自定义域名拜访,例如www.abc.com,在域名服务商增加CNAME记录,指向username.github.io, 而后在github pages 仓库设置中增加自定义域名, 这样通过www.abc.com 就能拜访github pages上面的 Actions 局部会介绍如何自动化部署到github pages,并且配置自定义域名 Hugo 介绍Hugo 是一个动态网站生成器,能够通过markdown文件生成动态网站,官网:https://gohugo.io/写好markdown文件后,执行hugo命令,在public目录生成动态网站,而后 将public目录推送到github pages 仓库github actions工作流 就是通过hugo命令生成动态网站,并且推送到github pages 仓库 ...

May 30, 2023 · 2 min · jiezi

关于devops:厚积薄发|迭代为什么叫冲刺

上士闻道,勤而行之;中士闻道,若存若亡;下士闻道,大笑之。不笑不足以为道。--《道德经》软件工程从原始的作坊式工作形式,通过了哪些思考、哪些计划的试探,才在一直地尝试与改善后,走到现代化的工程过程?在降级的路线上,经验了哪些挑战,以及针对这些挑战做了哪些计划,这些对于真正践行麻利工作形式具备重大的指导意义。本文将比照作坊式开发过程与麻利开发过程的区别,以实例的形式来总结这两个过程治理中的晋升点。 作坊过程形式(无组织式) 对于大多数公司来说都有一套残缺的研发流程,以撑持公司的研发体系。这样做最大的劣势是能够保障各个团队的行为规范的一致性,继而保障品质、速度、规范性的一致性。而作坊式的过程治理一个很大的特点就是各个团队之间没有对立的研发流程,导致更多细节性问题裸露。 论述过程分先后,但作坊式的过程治理的问题并不是先后呈现的。而是并发产生的,所以这里的陈说程序不影响问题的优先级和问题产生事件。上面讨论一下作坊式的过程治理中会遇到的问题。下文中以形象总结出的论断作为章节题目,再以实例来阐明题目。 |边界含糊边界含糊阐明两件事:业务边界含糊,工夫边界含糊。这两个含糊边界会导致投入的人力未知、品质问题收敛速度未知。所以,项目管理铁三角缺一项就会影响品质,作坊式过程中会缺三项能够说是没有做过程治理。 业务边界含糊业务边界含糊能够从几个方向阐明:业务需要过大导致的边界含糊在做过一个从零到一的 OAM(Open Application Model)的迭代过程中,须要对 OAM 建设 GUI,YAML 配置,版本过程,公布过程等等。每个过程都有有数的细节,例如:在管制利用下的正本数的时候不填代表什么?填0代表什么?填数有代表什么?再比方:在 OAM 中逻辑概念有十几个,每个逻辑概念能够作为一个逻辑实体。逻辑实体之间的关系会造成三联实体(三个实体之间的特定关系),有甚者会有四联实体。在这样简单的场景下总会漏一些在后期需要廓清时总有未想到的细节点,最终都遗留到线上才发现也是有的。 业务廓清含糊导致边界含糊在做业务廓清时,因为是BA/产品给研发/测试进行解说总会遇到廓清过程中基于现有的需要了解为某个个性确定为一个方向。但在开发过程中或业务上线后会意识到这个问题不应该在这个方向上,而应该在另外一个方向。例如:K8s 的资源管理器Helm界面上反对环境治理不须要反对依赖中的 values 文件作为指定文件,但起初须要反对。 版本公布导致的业务边界含糊私有化部署要做版本化,而后在公布 Saas 产品的时候又要归到版本中。在这个过程中 Saas 线上用户报的工单,Saas 线上用户的简略需要。到底应该在哪个版本来同步到私有化部署的版本中。因为 Saas 线上客户的需要,工单是须要放在当火线上的版本中的。这样就导致线上需要会上多个版本,如果版本会有一点不同那么就会造成版本差别问题。 工夫边界含糊工夫边界含糊能够从几个方向阐明:不做工作量评估,或以人员能力来做工期评估作坊式过程治理是将工作交给某个人或者交给两个人去做即可,具体什么工夫做完做成什么样就没人去管了。因为业务边界含糊导致,交付工夫不确定。任何时候都能够插入新的工作,导致每个人手中的工作越沉积越多。而后再推导出插入进来的工作先做,后面接手的工作又被延后了。从而导致手中重要的工作始终向后延期,而又无奈推动上线。 过大的开发量,导致评估不精确过长的开发周期间接上线,导致很多点未测试齐全,问题遗留到线上解决。问题定位都有可能忘了细节在哪里。 团队合作私有化部署与 Saas 服务不同,私有化部署必须在某个工夫点对齐性能之后再打版本。这样就会造成团队间合作。个别作坊式工作坊中不会在团队间造成工夫对齐理念,因为没有 PMO 来对齐与跟踪这部分。 |独立个体大于团队合作在作坊式过程的团队模式比拟失当的比喻是团队是一个职能型组织。职能型组织最大的特点是互相独立,专业化团队。在作坊式过程中这样做其实会产生更多的问题,例如:某局部工作再始终沉积而又没有方法加快进度、信息有余导致开发过程的验证有余从而导致品质飘忽不定、同时开启的工作事项越来越多失去重点。 合作过程不通顺团队关系以单个成员独立实现为主,不评审,不查看,不回顾。在这个过程中就会产生信息同步不通顺,无法说明的工作内容与进度,单个成员负责特定业务的问题。信息同步不通顺一个很简略的例子:OKR 的拆解过程须要从团队的 KR 拆解为团队成员的 O,在用团队成员的 O 进行具体的KR的拆解,这样会造成KR 又上层的 O 来撑持这个过程。然而在作坊式的团队中尽管应用了比KPI更加现代化的 OKR 来实现团队指标的制订,然而没有做拆解过程,没有指标起源的解说过程。那么团队的指标就没有方法落地到每个团队成员中,这样就造成信息不通顺问题。另外,信息是一种十分重要的资源。当之后某几个成员把握特定的信息后,他们就能够把信息作为利益替换资本。这样特定成员手里就多了筹码能够跟别人做利益替换。这样的事件多了是不是就很像传统的国企做事格调,要给某些不舔下级的团队成员穿小鞋的时候这个信息差就能够做到一些不利的事件。这是一种在作坊式工坊中的生存形式。无法说明的工作内容与进度只在业务上阐明一个大略要做的事件,再加上业务含糊问题。在不进行评审与设计,工作拆分的状况下就无法说明具体工作内容,无奈跟踪工作事项中的进度。能够在开发过程中来整顿是否做过设计,设计评审,工作拆分,工作量评估,工作跟踪等事项既可晓得是否已产生这个问题。单个成员负责特定业务职能型组织一个特点就是特定的团队实现特定的业务。而在作坊式团队中一个成员负责一块业务,而后如果这块业务最近不须要开发或保护则负责这块的团队成员就闲下来了。理解最多的业务模块的成员永远最忙。无业务备份团队成员概念。 同时开启的工作事项越来越多在开发过程中不设置阶段(里程碑)、不设置指标,从而把团队工作作为一个任何内容都能够插入的,都有必要插入的。在这样的状况下一个团队不论是 two pizza 团队还是更大的团队,只有是依据这样的规定就会始终开启新的工作项。作者在工作过程中见过一个团队同时开启十几项事务。例如:线上问题修改,KA 客户撑持,代码平安扫描问题修改,性能优化,客户小需要几个等等都同时开启。在这样的状况下,次要特色是布局与执行有问题。布局过程与执行过程无奈对齐导致了只做了紧急不重要的事,而做不了布局中的事项。 失落焦点失落焦点便是为什么叫冲刺的根因。后面说到工夫边界含糊,再加上上一节说到同时开启多想工作项。再加一个无周期的环境中又开启多个事项,而不是团队专一于一件事在固定周期内解决这一件事来放弃阶段的专一性。这样导致团队成员都很忙,然而又没有实现更多的事件。从而升高成员成就感,并对职位降职有较大的妨碍。因为职位降职须要说明在一个周期内为团队、为公司做了哪些奉献,在作坊式过程中做事既琐碎有误指标总结为奉献就会很难。 任性的成员越来越多团队指标缺失导致团队成员没有行为规范。没有行为规范各个成员就会依照集体了解对代码,开发标准进行施行。在开发过程中就会发现A想这样,B想那样最终就看谁更强硬。而不是看团队整体的指标输入价值,还是巩固品质就开始做本人的事件。导致各做各的,由此任性的成员就从这里进去。 独立个体大于团队合作事件堆积如山,再来新的事件必须排队进行。因为事项同时开启过多,导致每个成员要做的事件都是不一样的。每个人头上都是一堆事要做,而每个事件都有不同的头须要去牵扯进去再做,所以,没有方法去做。 |无过程CheckPoint因为没有里程碑的制订,就没有方法 check 打算执行状况。无奈跟进进度的状况下很容易造成互相职责,互相不信赖的过程。进入负反馈循环之后就会造成团队在泥沼中越陷越深,再加上作坊式过程无奈实现自我改善。 忽视危险技术危险、进度危险,在后期辨认过程中没有过程与办法来提出。在中期没有 CheckPoint 进行辨认。前期进行无回顾与总结更无奈在前期回顾危险。从而在整个研发过程中无奈进度测量和后果评估须要不同的办法。 忽视品质在作坊式工作过程中,工作事项会堆积如山。而在这个时候品质的劣势就更加凸显,在品质的成果不可显示展现进去。所以,就会竭力的压迫品质的投入。例如:开发实现测试用例编写,开发实现测试工作,开发实现验收上线工作。这样很容易造成陷入固有思维陷阱,导致问题在线上裸露。 静止式治理作坊式治理就是没有规矩,想一出是一出。例如:前两天发现线上问题比拟多,而后就开始问品质人员为啥没测进去。过两天线上问题少了就又忘了这一出。再跟上没有过程改良,复盘又无奈做到根因剖析。所有的过程治理都流域外表无奈解决根本性的问题。 |论断 初步总结一下作坊式过程,其实还有很多事件无奈深刻探讨。例如:这样的团队中的成员对于过程治理的认知是什么样的?这样的团队中文化是什么样的? 难以响应内部变动永远在响应变动,那就是没有响应变动。因为永远响应变动那就没有工夫去做本人应该做的事件,例如 OKR,KPI 事项。而在依据 OKR 引申到要撑持的业务方向的变动就更难进行撑持。 ...

May 24, 2023 · 1 min · jiezi

关于devops:建设一站式DevOps平台腾讯云研发效能提升实践

本文作者:张渝导语 | 近年来,研发效力晋升越来越受到业界器重,许多厂商都在一直摸索研发效力晋升之路,从而实现研发效率和品质的继续优化,以应答日趋简单的产品开发。那么腾讯云的研发效力相干工作是如何发展和落地的呢?明天咱们特邀了腾讯云研发效力工作组负责人、腾讯衰弱副总裁 张渝老师,他将带大家深刻理解腾讯云研发效力晋升之路,同时也给大家解读将来腾讯云研效的倒退方向。 探析腾讯云研效痛点和解决思路近几年,腾讯云在整个研发过程中遇到的痛点,在我看来次要能够归结为三点:标准规范、工具平台、文化宣传。具体而言,首先,因为腾讯云业务波及的研发人员和业务产品数量宏大,而每个团队都有本人的标准和研发模式,但从整体上看,无论是在代码层还是工具层,咱们都不足更高层次的统一标准和标准。 其次,此前腾讯云的工具平台并不欠缺,各种工具从需要到代码到 CI、CD 到线上部署都有,然而工具与平台之间相互割裂,没有造成对立整体,需要对接、代码治理、构建公布和经营数据监控都在不同平台上实现,从而导致效率升高。此外,腾讯云倒退多年,一些工具平台年久失修,不足保护,且呈现了反复建设的状况。对于新员工而言,面对泛滥平台和工具他们也有些手足无措。因而,咱们必须尽快将这些平台纳入对立保护。 第三方面是文化宣传。咱们心愿在腾讯云外部,所有人都能意识到进步研发效力的重要性,并违心投入更多精力独特建设。因而,在推动研发效力晋升方面,咱们采取三种形式:第一,制订对立的标准规范,使大家逐步采纳咱们举荐的支流规范;第二,把工具平台做成一站式串联,造成一个对立的整个腾讯云共享的研效平台;第三,增强宣传疏导,让大家独特关注和参加。能够说,研效的建设是研发治理、工具建设和文化宣传三者的独特作用后果。 针对上述存在的问题,咱们次要的建设思路是采纳金字塔模型,最终目标是在研效平台上实现从需要到最终运维的一体式全过程,进步一线研发和运维的幸福感。金字塔的底层是各种工具的欠缺,咱们将筛选已有的支流工具增强自动化能力。第二阶段通过一站式门户将工具串联整合到平台上,实现从需要到最终监控的全过程。第三阶段将实际 DevOps 理念,尤其是从利用视角贯通整个流程。最上层是价值体现,通过数据度量跟踪,来体现所有的研效晋升工作是否合乎预期,如果合乎构想的轨道再往前推动。下图是腾讯云研效平台的理念和思路。 接下来将具体合成研效平台的各个档次和咱们所做的工作。下图中左侧的导航栏集成了次要的研发过程和应用的工具,不仅仅是将入口对立在一起,更重要的是将各零碎与腾讯云进行深度联合和买通,这是研效工作的根本要求。 第二个层级是 DevOps 信息集成。咱们立项时就制订了与腾讯云原生的单干规范,与自研业务的云原生化并行,一方面是容器化云原生搬移,另一方面是研效工作的晋升,帮忙进步腾讯云自研产品的效率和品质。在 DevOps 中,强调了从利用治理的角度来看整个生命周期,以进步操作效率。从微服务代码框架到配置、后端云函数调用、协定治理、集成公布等,都通过平台实现,构建并公布到云上,反对私有和公有部署。 第三个层级是自动化。咱们竭力推崇自动化执行理念,并且在整个过程中,以底层为根底,尽可能实现状态流转之间的自动化操作。通过各种音讯,触发各角色制订规范的工作流,从而实现继续的开发、测试和部署。 最初是价值度量。咱们定义了几个外围指标来观测和跟踪,长期度量咱们的价值,指引研效工作的继续改良和晋升。咱们订立了四个指标:部署频率、变更前置工夫、变更失败率和服务复原工夫,这些指标间接反映了研发工作效率和品质。 腾讯医疗研效晋升最佳落地实际腾讯云在研效工作方面遇到的一些挑战和痛点,在推动具体业务落地实际上也存在。以腾讯医疗业务为例,咱们发现在研发过程中,业务快速增长和简单的业务逻辑导致了研发效率降落和问题定位艰难等问题。 为了解决这些问题,咱们采纳了按域划分问题和分域解决的思路。具体来说,咱们将研发团队分为开发域、构建域、测试域、部署域和经营域,并依据整个研发流程的生命周期,按域划分和解决问题。咱们的解决方案包含对立代码标准、规范开发模式、自动化工具、继续集成、自动化回归测试、缩小人工染指、建设可观测体系等。同时,咱们也着重增强团队文化建设和技术交换,晋升团队合作和单干效率,独特推动研效晋升。 在具体业务落地实际研效晋升方面,咱们须要依据具体业务场景制订相应的研效晋升策略,并联合团队理论状况和行业最佳实际,进行继续优化和降级。此外,咱们发现研效晋升须要全员参加和独特推动,而不仅仅是技术人员的责任和工作。因而,咱们还须要增强团队培训和技术遍及,进步团队整体程度,造成良好的研发文化和合作机制,以保障继续的研效晋升和翻新驱动。 在开发畛域,不足对立的开发流程会导致测试阶段容易受到相互影响,呈现测试环境笼罩等问题。此外,因为需要没有与分支造成绑定关系,代码追溯变更或问题排查会变得艰难。团队刚刚成立时,因配合默契度不高也会导致合作效率低。为此,咱们采取了三个措施:对立开发模式-分支开发、骨干提测;将 TAPD 需要与分支绑定,解决追溯问题;引入个性开关以反对并行开发,从而提高效率并解决以前互相烦扰的问题。 在服务治理方面,咱们确立了一系列规范,如对立模块目录构造、为服务减少 DevOps 能力、以及对立组件等。咱们还开发了规范组件,并将这些规范传播给团队,从而实现服务标准化。通过引入脚手架,咱们实现了开发流程自动化并进步了效率,同时保障了品质和对立标准的指标。 在整个开发过程中,团队也在继续提倡和实际测试左移的概念,次要依附单元测试和代码评审 CODING。通过 CODING 插件自建自动化流水线,将单元测试视为品质门禁。同时,咱们在团队外部建设文化氛围,与员工激励相结合,以进步参与度。 在测试畛域,咱们次要面临环境治理方面的问题。为此,咱们采纳了增量复制和路由治理等改良措施来优化资源耗费和升高对业务的侵入。另外,在部署方面,咱们进步了自动化经营覆盖率,通过流水日志主动生成测试用例,并借助公司工具平台实现了流量回放。在经营方面,咱们应用腾讯云可观测当前,可能疾速定位和解决问题,从而提高效率并升高复杂度。 综上所述,咱们通过对立开发模式、标准、自动化脚手架、欠缺 CI/CD、强化单元测试、欠缺继续公布和构建流程等措施,在开发、构建、测试、部署和经营等畛域不断创新,进而提高效率、降低成本,并优化了团队文化和经营管理体系。 腾讯云研效工作将来布局目前,鉴于腾讯云曾经实现了各工具域之间的互联互通,但在我的项目外部的互通以及我的项目之间的互通方面依然存在一些缺失。因而,将来腾讯云的研效工作,咱们的重点是致力于继续强化我的项目外部的互联互通,并在跨 BG 方面实现更多的效率晋升。 此外,另一个维度则是扩大视角。目前,平台次要以利用为视角来组织连贯各功能模块,那么咱们的下一步打算是在此基础上扩大到我的项目视角,以理解各利用之间的关系。甚至咱们能够从产品业务视角来对待多个我的项目之间的关联关系,摸索进一步晋升的空间。 简言之,只有抓住研发效力实际、平台、以及度量这三点,能力无效晋升研效工作。咱们整个研效的外围思路是通过研效实现,平台在此基础上输入外围研效指标,以推动业务方进步研效性能,最初使得正向加强回路。 毋庸置疑,研效晋升是一项持续性工作,咱们也非常期待通过研效晋升,赋能腾讯云业务的进一步倒退。 点击此处链接,助力企业研发效力晋升

May 22, 2023 · 1 min · jiezi

关于devops:双模齐下提质增效CODING-携手知微共创-BizDevOps-体系新篇章

为了晋升工作和管理效率,工具建设是许多企业不得不面对的事实,然而在工具建设落地过程中,往往存在一系列的问题。如不同组织、部门之间互不相通,各自为政,工具流程与理论工作所需不符,导致工具建设的后果是人去适应工具而不是工具来辅助人。 由此可见,工具体系若建设不佳,非但无奈起到晋升效率的作用,反而会引发新的问题。这种状况在协同简单的大型组织架构下尤甚——业务团队与研发团队之间长期不足无效沟通、软件研发过程不通明等,这些问题事实上能够通过正当的工具体系建设失去无效解决。 正是在上述背景之下,CODING 与知微决定强强联合,施展各自劣势,将价值流与工作流两种模型相互补足,独特为企业提供从业务到研发、运维的一体化 BizDevOps 解决方案,满足企业对工具的灵活性、标准化等多元化需要,促成企业跨部门合作,进一步开释组织效力。 为什么在 DevOps 之后,又呈现了 BizDevOps ? 大家是否思考过这个问题? 难道单纯只是制作一个噱头? 显然不是。 DevOps 无奈解决所有的问题咱们认为 BizDevOps 这样的提法之所以开始在业界风靡,背地的外围在于,DevOps 流行许久以来,企业慢慢意识到「DevOps 无奈解决所有的问题。单纯引入 DevOps,许多治理问题仍然无解」。 这是因为,DevOps 的作用是晋升每一个独立的开发工作的效率。比如说,同样开发一个性能,没有建设 DevOps 工具链要花 4 个周,而有了 DevOps 工具可能只有花 3 周。 就如同从上海到北京,当没有飞机这种交通工具的时候,你搭乘火车或者更原始的交通工具所须要的工夫会更多一些。 然而,企业当下面临的问题,事实上不是单个具体的工作执行慢,而是在更上游——需要拥挤。 形象一点说,上海到北京的飞机仍然是 2 小时,但问题是你到机场的工夫太长了——因为公路上重大堵车——去机场路上所花的工夫远远比在飞机上的工夫要多。 这一点通过研发团队的需要流动效率就能够佐证,大部分的工夫并不是在开发,而是在散会、协调、对齐需要等等。 这也是业务与研发之间仿佛总是矛盾重重的起因所在,业务认为需要提出来之后总是迟迟无奈上线,而研发则认为本人曾经很快了。 针对企业目前所面临的上述窘境,知微与 CODING 决定施展各自的劣势,帮忙企业解决理论的问题: 知微的劣势是对业务到研发端到端的价值流治理(疏解拥挤,让你更快地到达机场),而 CODING 善于的则是上游的开发的工作流治理(让你搭飞机而不是徒步或者火车),各取所长,双流合一,目标是真正可能帮忙企业达到提质增效的指标。 各取所长,双模齐下价值流与工作流,两者自身并无高下之辨,然而其实用场景确实有差别。 价值流适宜较为简单、灵便、多角色、高频互动的工作场景;而工作流则适宜流程高度标准化的、边界清晰的工作场景。 用适宜的办法来治理适宜的工作,便事倍功半;而假使办法与理论状况牛头不对马嘴,轻则事倍功半,重则作茧自缚。 在一个企业外面,很难以一套既定的办法治理好所有的事项。 (BizDevOps平台布局全景图/Agilean于2023年初首发) 因而,用对的办法管对的事件,很重要。 知微知微的劣势在于可能依据不同企业的业务特点和组织架构灵便地构建治理模型,对实体组织构造、人员、有形的业务价值流等进行数字化映射,建设对立的治理对象以及对象间的连贯关系。 有利于从需要提出到上线的开发全过程治理,建设研发治理现场,通明协同过程,及时畅通阻塞,减速价值流动。 CODINGCODING 的劣势在于其标准化、自动化的 DevOps 工具链,笼罩软件研发全生命周期。在代码托管、我的项目协同、测试治理、继续集成、制品库、继续部署、云原生利用治理等各个环节都具备成熟的解决方案,可能减速每个确定的、标准化的研发工作的流动,疾速、稳固、继续地公布软件。 CODING与知微联合,可能帮忙企业构建起业务价值交付的治理对象价值流,真正落地 BizDevOps 实际,买通从业务到开发、运维的端到端全链路和反馈闭环。 价值流叠加工作流的双流模式之下,可能无效解决零碎割裂(切换老本)、信息不同步、只有工作流没有价值流、数据与理论工作两张皮等问题。 咱们能够为企业提供哪些便当具体而言,目前CODING与知微曾经实现了「治理单元对应」、「动静双向同步」、「代码仓库数据回写」、「度量信息回传」等性能,从开发执行、协同互动、高效治理等多角度多层面,为企业发明便利性。 (知微集成CODING示意图) 治理单元对应 ...

May 20, 2023 · 1 min · jiezi

关于devops:极狐-GitLab-重磅发布新产品极狐星让研发效能看得清算得准成就企业精英效能管理

在研发驱动业务增长的明天,越来越多的研发管理者发现: 总是感觉研发资源不够用? 如何用数据掂量研发效力? 如何定位软件交付瓶颈? 怎么治理并预警我的项目状态? 想尽早发现代码泄露危险怎么办? 为了更好地服务极狐GitLab 10 万 + 企业研发管理者,极狐团队历时一年,历经上百次调研访谈,重磅推出极狐星(TowerFox)。 极狐星(TowerFox)是基于极狐GitLab 的一站式企业 DevOps 智能剖析治理平台,提供从数据驾驶舱、效力治理、项目分析到合规治理的一体化解决方案,可能全行业、多场景、全软件生命周期的满足企业研发治理需要,让研发效力看得清,算得准,成就企业精英效力治理。 目前,极狐星曾经过 14 个版本迭代。在内测阶段,即取得蔚来、AutoX、轻舟智航等十多家头部客户的高度认可。 其中,蔚来主动驾驶 DevOps 团队负责人孔毅示意: 应用至今,极狐星以其数据采集无感知、数据度量可视化、研发效力体系化等诸多劣势,已帮忙蔚来实现用数据度量研发效力,后续蔚来外部会有更多团队应用极狐星,无需多言,极狐星产品自身就是最好的举荐。如果您对极狐星感兴趣,欢送点击限时 50 席收费体验极狐星! 无需简单集成,数据采集零感知极狐星基于极狐GitLab 开发,突破数据孤岛,不用放心简单集成与适配,「需要→设计→开发→测试→交付→运维」,DevOps 全流程效力数据采集与解决零感知,帮忙企业轻松贯通软件研发全生命周期。 一个驾驶舱,从海量研发数字凝练为治理洞见极狐星以丰盛的数据可视化图表多维出现,包含企业我的项目代码提交榜单、我的项目语言占比、企业自动化成熟度等多个研发外围指标,总览企业 DevOps 效力全貌。 并反对我的项目细粒度数据下钻展现,帮忙管理者从海量研发数字,轻松凝练为治理洞见与卓越实际,为效力晋升提供策略根底。 基于数据驱动的五器重角,全面评估企业 DevOps 效力一个企业 DevOps 效力如何评估,能够总结为:「谁在做」、「做得快不快」、「做得好不好」、「是否又快又好」、「当前怎么改良」几个视角开展。 极狐星基于软件全生命周期数据,构建五重效力剖析与治理视角,通过先进的体系化效力模型,帮忙企业更高效地应答市场变动。 1. 谁在做——研发人员效力评估研发团队负责人总是感觉资源不够用,难以反对业务倒退。 极狐星通过实现议题数、合并申请数、代码行数、提交次数的指标统计,直观展现团队及人员效力。 在团队层面,盘点现有研发资源,评估分工与产出是否正当;在人员层面,帮忙企业回归人的视角,理解开发者集体质效体现,从工夫维度量化不同人员成长轨迹。总结一下,极狐星帮忙研发团队搭建提供决策依据,从而实现衰弱且稳固的高效交付。 2. 做得快不快——流水线效力评估业务需要,从提出到开发,要多久上线?这是每个研发人员都必须面对的挑战。 极狐星全面出现流水线总数、胜利/失败流水线个数及散布占比、均匀运行时长及频率、红灯均匀修复时长与期待时长等,「绝对值」横向展现数值 +「数据趋势」纵向比照,流水线效率尽在把握。 另外,极狐星反对原始明细数据导出,为后续深度剖析奠定根底。 3. 做得好不好——代码品质评估极狐星与极狐GitLab 弱小的 Code Review 能力相结合,无需简单对接,主动统计代码覆盖率、代码问题数、品质门禁次数等要害质量指标,确保品质问题可追溯,严格落实品质标准。 4. 是否又快又好——交付效力评估软件交付的「快」与「好」并不一定相对矛盾,但永远是管理者最难以均衡的要害。 国内出名 DevOps 调研与钻研组织 DORA(DevOps Research and Assesssment)认为,以下四个指标能够无效评估软件交付体现: 部署频率;变更前置工夫;变更失败率;复原服务工夫。极狐星率先引入国内当先的 DORA 交付指标体系,自动化展现 DORA 外围指标数据趋势与平均值,通过「变更前置工夫」+「部署频率」把握研发对业务需要的响应速度,通过「复原服务工夫」+「变更失败率」验证服务稳定性及故障响应水平,确保团队「效率」与「稳定性」间找到最佳平衡点,软件交付又快又好。 ...

May 19, 2023 · 1 min · jiezi

关于devops:实践容器镜像扫描Get-云原生应用的正确打开方式

 容器技术的衰亡,让应用程序更加轻量化和可移植,大大提高了利用交付效率。但容器中的利用也面临各种平安威逼,容器及其镜像平安不可小觑。 近日,在「DevSecOps 软件平安开发实际」课程上,极狐(GitLab) 高级业余服务交付工程师唐恩、极狐(GitLab) 研发经理张頫,分享了容器镜像扫描的原理及代码实现,并演示了极狐GitLab 容器镜像扫描性能,帮忙大家进一步把握容器平安。 以下内容整顿自本次直播,你也能够点击观看视频回放或下载 PPT。Enjoy~ 什么是容器镜像扫描?首先,回顾 2 个基本概念: 容器:一种打包形式,用于封装应用程序的代码和依赖项,使应用程序与底层基础架构拆散,使其能够在不同环境中运行。容器技术大大提高了利用交付与迁徙效率,尤其在云原生场景下,其价值更加凸显。Docker 是目前最为风行的容器计划。容器镜像:用于创立容器的文件模板,存储了运行环境和利用所需的文件系统及软件。通过应用不同的容器镜像,能够创立出运行不同利用或操作系统环境的容器实例。容器镜像扫描则是指对容器镜像进行平安检测的过程,属于 DevSecOps 中 Sec 的一环。通过检测和评估已知威逼与破绽,最大限度升高危险,确保镜像安全性与衰弱性。 为什么要进行容器镜像扫描?容器技术给软件交付带来前所未有的灵活性与效率,但也不可避免地减少了平安面临的不确定性。 近年来,各种报告和统计数据显示,容器平安正受到越来越多的关注,这也推动容器镜像扫描等平安防护措施的广泛应用。 例如,Datadog 公布的报告显示,目前已有 25% 的公司采纳了 Docker 技术,相较前一年晋升 6%,表明 Docker 使用率快速增长,渗透到了越来越多企业中。 同时,Sysdig 公布的容器破绽报告显示,目前有 75% 的容器存在重大或危急级别的破绽。这表明容器平安成为严厉问题,须要企业高度重视。 容器技术带来的便当,与容器平安,两者如何兼得?容器镜像扫描等平安工具和机制成为解题要害。 极狐GitLab 容器镜像扫描 4 大劣势➤ 一站式平台,无需额定工具 极狐GitLab 自身是一站式 DevSecOps 平台,内置集容器镜像扫描,无需装置和保护额定工具。 ➤ 简略易用,一行配置高度自动化 容器镜像扫描属于极狐GitLab 流水线模板之一。用户在流水线配置文件中,通过 include 字段即可援用,容器镜像扫描整个流程就会主动实现,包含拉取镜像、启动扫描器、生成报告等步骤。 ➤ 灵便管制,高效和平安完备 容器镜像扫描能够利用于开发、构建、测试、生产等各环境,实现容器镜像全生命周期的平安治理。 得益于极狐GitLab 弱小的流水线性能,用户能够通过配置将把容器镜像扫描管制到某一阶段中。例如在开发环节,不进行容器镜像扫描;在公布环节主动触发容器镜像扫描,灵便管制,达到既高效又平安的目标。 ➤ 报告可视化,清晰详尽便于解决 容器镜像扫描实现后,通过 CI/CD 流水线中的 artifacts 关键词指定将报告输入为 JSON 文本,并主动解析为可视化报告(如下图),报告中蕴含镜像概述、检测到的破绽清单、危险等级等信息,清晰详尽,不便用户剖析与解决。 除了在极狐GitLab 流水线界面能够查看破绽报告,在「平安与合规 → 破绽报告」也可查看最新破绽状况(如下图)。 由 Merge Request 所触发的容器镜像平安扫描,可间接在 Merge Request 页面中查看报告(如下图),不便用户更好地审查代码。 ...

May 18, 2023 · 1 min · jiezi

关于devops:IDP-与-DevOps平台相似之处与关键差异

软件开发是一个简单而动静的过程,波及许多工具、技术和实际。为了更快、更好地交付软件,开发人员须要无效地合作,主动执行工作,并治理环境。然而,因为软件架构的日益简单,工具和平台的多样性,以及对平安和合规性的要求越来越高,软件开发变得极具挑战。  为了更好地应答开发挑战,企业依据本身状况别离抉择外部开发者平台(IDP)和 DevOps 平台,这些解决方案通过为布局、编码、测试、部署和监控应用程序提供一个对立的框架,帮忙团队简化其软件交付生命周期,进步了生产力和速度。  在这篇文章中,咱们将对 IDP 和 DevOps 平台进行比照,一起探讨两者的相似之处与要害差别。  IDP与DevOps平台:改善软件开发的相似之处IDP 和 DevOps 平台在指标、办法和流程方面存在一些相似之处。  首先,IDP 和 DevOps 平台都旨在进步软件开发的效率和效益。IDP 的次要重点是通过提供一套标准化的工具、基础设施和流程来进步开发人员的生产力和合作。另一方面,DevOps 平台的次要重点是通过自动化和整合软件开发过程的所有阶段来实现疾速和牢靠的软件交付。这两个平台的指标都是为了使软件开发更快、更高效、更无效。  同时二者都应用自动化来简化和精简开发过程。自动化是这两个平台的一个基本特征,因为它能够让开发人员专一于更要害的工作。IDP 能够自动化常见的开发工作,例如构建和测试代码,并为开发人员提供自助服务工具,以治理他们本人的开发环境。同样,DevOps平台能够使整个 CI/CD 过程自动化,从代码开发到生产部署,这能够帮忙缩小交付软件更新所需的工夫和精力。  二者的要害理念都是通过提供一套标准化的工具和流程,供开发人员和其余团队成员应用。IDP 提供了一套标准化的工具和基础设施,如容器化技术,以创立一个标准化的开发环境供不同团队和我的项目的开发人员应用。同样, DevOps 平台提供了治理基础设施即代码的工具,这能够帮忙确保基础设施在不同环境中的一致性和可重复性。  此外,合作和沟通对于胜利的软件开发至关重要,这两个解决方案都专一于改善开发团队成员之间的合作和沟通。IDP 提供了版本控制、代码审查和合作的工具,帮忙开发人员更无效地单干。同样,DevOps 平台能够提供工具来监测应用程序的性能和可用性,并收集和剖析指标和日志,帮忙疾速辨认和解决问题。  IDP 和 DevOps 平台的目标都是为了缩小建设应用程序所需的工夫和精力。理解这些相似之处能够帮忙企业在决定应用哪种平台以及如何将其整合到他们的软件开发流程中做出适合的抉择。  IDP 与 DevOps 平台之间的要害差别尽管 IDP 和 DevOps 平台都旨在改善软件开发,但在实现形式和应用场景上存在一些不同之处。接下来通过三个具体实例,来探讨 IDP 与 DevOps 平台的要害差别。  实例1:配置基础设施软件开发人员须要执行的常见工作之一是为他们的应用程序提供基础设施。例如包含创立服务器、数据库、负载均衡器、网络等等。  通过 DevOps 平台,开发人员须要应用各种工具和服务来配置基础设施,如云供应商、配置管理工具、协调工具等。开发人员必须学习如何应用这些工具和服务,如何正确配置,以及在出错时如何排除故障。开发人员还必须与经营团队协调,以确保基础设施合乎平安和合规要求。  而在 IDP 上,开发者只需点击几下,就能够疾速配置基础设施,通过应用平台对立的界面,形象出根底工具和服务的复杂性。开发人员能够从预约义的模板或者依据他们的须要和偏好的定制化配置中进行抉择。开发人员还能够应用自助式护栏,确保基础设施满足平安和合规性要求。  案例2:部署应用程序软件开发人员须要执行的另一项常见工作是将应用程序部署到不同的环境,如开发、测试、暂存和生产。  通过 DevOps 平台,开发人员须要应用各种工具和服务来部署应用程序,如源代码管理工具、继续集成和交付工具、容器化工具等。开发人员须要具备应用相干工具和服务的相干常识和技能,例如怎么将工具互相整合,以及如何在部署过程中进行监控等。开发人员还要与经营团队协调,以确保部署的胜利和牢靠。  在 IDP 上,开发者能够通过点击或简略的命令来部署利用。开发人员能够从事后定义的流水线或工作流程中进行抉择,而这些流水线和工作流程都是依据开发人员的需要和应用偏好定制的。同时开发人员还能够应用自助服务反馈回路,确保部署胜利和牢靠。  实例3:管理应用程序第三个软件开发人员须要执行的常见工作,是在应用程序部署后对其进行治理,例如扩充或放大其规模,用新性能或谬误修复来更新它们,在呈现谬误时回滚等。  在 DevOps 平台上,开发人员须要应用监控工具、日志工具、警报工具等,来管理应用程序。因而,开发人员须要学习如何应用应用这些工具和服务,学习剖析和解释它们提供的数据,以及了解在须要时采取行动。此外,开发人员还须要与经营团队进行沟通与协调,以确保应用程序顺利和平安地运行。  而在 IDP 中,开发者能够通过外部开发者门户来管理应用程序,同时还能够拜访自助式仪表盘和报告,以获取无关其应用程序的相干和可操作信息。  根据上述三个利用场景,能够总结出 IDP 与 DevOps 平台的要害差别:  ...

May 17, 2023 · 1 min · jiezi

关于devops:极狐GitLab-as-Code全面升级你的-GitOps-体验

 近日,由微软和英特尔联结发动的第二届开源云原生开发者日(Open Source Cloud Native Developer Day)上海站顺利闭幕。极狐(GitLab) 资深云原生架构师郭旭东在会上进行了《深度摸索 GitOps 平台的更多可能》主题演讲,与泛滥开发者共赴技术 “狂飙” 之旅。 以下内容整顿自本次演讲。Enjoy~ 什么是 GitOps ?对于 GitOps 的定义,千人千面。咱们这里将 GitOps 概括为一个公式: XaC:Everything as Code,这是 GitOps 的重要个性之一:所有皆代码。例如 Infrastructure  as Code 基础设施即代码;MR&PR:PullRequst & MergeRequest,合并申请;CI + CD :Continuous Integration & Continuous Deployment/Delivery,继续集成与继续交付或部署。GitOps 领有四个要害准则: 申明式形容:因为 Git 充当所有 DevOps 操作的繁多事实起源,因而整个零碎在 Git 中应用 .yaml 文件进行申明性形容。申明式形容指标的性质,让计算机明确指标和后果,而非流程。它不必通知计算机问题畛域,从而防止随之而来的副作用;版本控制:须要的零碎状态在 Git 中进行版本治理,能够齐全跟踪在任何给定工夫点对系统状态所做的所有更改;自动化:能够在 Git 代码中申明零碎所需的状态,而后自动化零碎以将所有批准的更改利用到零碎;保障:当所需状态与零碎的理论状态不匹配时,软件代理会揭示配置更改,来确保差别的修改和告警。同时,GitOps 也具备幂等性个性,即同一个操作,无论执行多少次,跟执行一次的成果一样。这是一个重要的个性,使得 GitOps 模型在各种异常情况下都能正确复原。 因而,GitOps 在版本治理、分支策略、代码审查、历史记录、用户体验等方面天生具备劣势。 如何构建高质量的 GitOps 平台?GitOps 平台则是一种将 GitOps 工具与其余工具和服务集成在一起的平台,旨在提供更残缺的 DevOps 自动化解决方案。 GitOps 平台通常须要提供以下能力: GitOps 工具治理:将不同的 GitOps工具集成在一起,能够主动管理应用程序的部署、配置和更新。自动化流水线:提供自动化管道,从代码提交到应用程序部署和监控全过程自动化。代码审查:因为每一次代码提交都可能间接影响到云等根底设置,因而每次批改都须要充沛 Review。平安工具:提供安全性性能,如自动化破绽扫描、访问控制和加密等。2 种平台计划搭建 GitOps 平台须要综合思考老本 + 效率 + 体验,通常有两种计划: ...

May 16, 2023 · 2 min · jiezi

关于devops:AI-DevOps-ChatGPT-与研发效能效率提升中

# 为啥 ChatGPT 忽然火了? 简略概括就是:产品太过惊艳,体验超预期 之前人工智能倒退多年,报道最多的兴许就是已经的李世石大战AlphaGo,事实中的特斯拉主动驾驶,还有波士顿动能放出的机器狗。对于圈外人士来说个别也接触不到这些,仅仅看看而已。然而 ChatGPT 不一样,一声巨响,石头中蹦出一个 ChatGPT,天生具备人类智慧,能够应答人类各种刁钻问题,甚至还能够给他一些材料,让他「现学现卖」疾速学习后给出反馈。这就先进得有点不讲道理了。 ChatGPT让用户疾速抓到它的价值仅仅技术上的冲破就会火么?不是的。技术为产品服务,产品为用户服务。技术上的冲破要融入到产品中去,让用户通过产品疾速体验到其价值。这要从那个扭转了人们对人工智能认知的对话框说起。 之前找货色都是关上搜寻页面,搜寻关键词,看到后果后,在各种后果中寻找本人想要的答案。然而自从有了 ChatGPT,所有都变动了。 关上ChatGPT,用你最相熟的语言形容出你心中的问题,ChatGPT「间接通知你」答案,而不是给出各种后果,让你本人判断。不称心的话,还能够把你的问题形容得更加具体,更加细化,以便于 ChatGPT 深刻理解你心中所想。对,就是这么简略。ChatGPT 省去了大量辨认、演绎总结、翻译、文档排版等工作,极大进步了工作效率。 ChatGPT带来流量源头之争ChatGPT 的呈现极大打压了一众搜寻起家的公司,包含百度,谷歌。尽管百度公布文心一言后股价有所回升,然而那体验成果间隔ChatGPT至多还有1-2年的差距。谷歌的股价也大幅承压,然而谷歌技术底蕴厚啊,立即合并旗下两大人工智能钻研部门Google brain 和 DeepMind。5月10日,推出了Gecko、Otter、Bison和Unicorn四种规格的 PaLM 2。一举挽回了颓势,重塑人工智能科技公司位置。 一个另类是微软,因为其对OpenAI 公司胜利的投资,拿到了 AGI 的第一张门票,稳坐人工智能头牌,一直把 OpenAI 的成绩融入到自家产品线中,公司股价连创年内新高。 一个聊天对话框扭转了认知。当大家越来越多地利用 ChatGPT,和其对话。与其交换的越多,ChatGPT就会越智能,给出的答案也越精确,大家应用搜索引擎的机会也就越来越少。这是一场流量入口争夺战,所以各大搜寻公司都要去做,哪一个都输不起。 ChatGPT带来的新机遇就以当初 openAI 放出的 ChatGPT3.5能力,给OpenAI一个百度(419亿美金)的估值是不是低了?给半个谷歌(1.5万亿)的估值不过分吧?而当初OpenAI 的估值才300亿美金。 国内大佬一把梭,纷纷下场投入到 AGI 的守业浪潮。前有王慧文光年之外,王小川五季智能,后有阿里、京东等公司进去的大佬。为啥一时间这么多大佬入场?我个人感觉还是 ChatGPT 带来的逆天体验,太过惊人,产品价值太过震撼。 目前为止做 AGI 相干的新公司不止50个。 ChatGPT目前存在的问题当然咱们也须要意识到目前还有一系列问题,ChatGPT 须要解决,比方: 数据隐衷问题:前些天产生的ChatGPT 透露用户银行卡号的问题;三星员工把代码和出错信息输出到 ChatGPT中,造成泄密的问题。都是活生生的例子。价值观问题:Elon musk 仍然对 ChatGPT 能够写出赞美拜登的文章,不能写出赞美特朗普的文章感到悲观。ChatGPT也会「瞎诌胡扯」,有些答案基本对不上。而有的答案看似正确,然而因为没有上下文,还须要通过搜寻找可信源确认下。本文总结尽管 ChatGPT 还有那么一点点瑕疵,然而瑕不掩瑜,ChatGPT 给用户带来的体验曾经足够震撼。在人工智能技术的帮忙下,软件开发流程和形式也正在产生改革。ChatGPT 曾经体现出了其大幅晋升软件研发效力的能力,软件开发曾经进入人工智能时代。 我的其它文章DevOps|AGI : 智能时代研发效力平台新引擎(上) DevOps infra | 互联网、软件公司基础设施建设(基建)哪家强? devops|中小公司不要做研发效力度量 devops|中小公司效率为王,没必要度量 研发效力生态残缺图谱&DevOps工具选型必看

May 15, 2023 · 1 min · jiezi

关于devops:DevOps|AGI-智能时代研发效能平台新引擎上

AGI 的呈现,给了咱们一个新视角去扫视咱们做过的零碎,尤其是研发效力平台。研发效力平台作为一个工具平台,实质就是进步公司整体产研的效率。AGI 的疾速提高大家曾经引人注目,本文就是在我的项目协同,代码治理、测试、AIOps等方面来探讨 AGI 能够给研发效力平台带来的巨大变化效率晋升。拥抱 AGI,吸纳 AGI 来改善和降级咱们的研发效力平台。应用人工智能进步研发产能和效率是当下的重要趋势,AGI技术作为人工智能的前沿,必将成为推动研发效力新一轮飞跃的关键技术。 研发效力是一个组织高效交付产品的能力,以及围绕进步这一能力所建设起来的由标准、流程、工具、度量体系、实际等组成的系统工程体系。指标是优化开发者体验,夯实产品研发经营基础设施和赋能组织继续高质高效地交付产品价值。 laofo@scmroad ChatGPT次要性能我(ChatGPT)是一个基于OpenAI的大语言模型,能够用于生成文本、答复问题、实现工作和提供倡议等方面,次要性能包含: 文本生成:能够依据用户提供的主题或关键词生成文章、段落、句子等内容。问答零碎:能够答复用户提出的问题,并尝试提供相干信息和解释。语言翻译:能够将一种语言翻译成另一种语言,并尝试举荐最合适的翻译。情感剖析:能够剖析给定文本的情感色调,并提供相干倡议和反馈。工作实现:能够基于用户的工作需要,尝试提供解决方案和倡议。总的来说,我可能解决各种类型的文本数据,并尝试提供最适宜用户需要的答复、倡议和解决方案等。 下面是ChatGPT 给出它本人能做哪些事件。ChatGPT不是 AGI 的全副,然而至多咱们能够通过ChatGPT发现一些状况。上面我就会把ChatGPT的次要能力和研发效力平台外围性能联合起来,谈谈到底有哪些扭转。 AGI+我的项目协同主动创立文档构造和框架:比方我要写一份产品需要文档,我间接在某个目录下点击 AGI 机器人,通过语音或者文字通知它,帮我生成一份产品需要文档,AGI 就能够主动帮我生成一个模版式的文档和局部内容。如果 AGI 通过一些训练,这个文档的内容会更空虚和正确。润色、审查、辅助编写文档:比方我曾经有一份曾经写好的文档,这时能够把文档地址发给 AGI,让它看下文档内容是否有逻辑上的问题,形容得是否精确,同时还冀望它能主动帮我修复有问题的局部。语音/视频输出生成文档、不便检索和查看:比方咱们在聊天或者散会的时候能够关上 AGI。当会话完结时,AGI能够主动帮咱们把聊的内容生成一份会议纪要,由工夫线形成的文档,有总结,有待办,甚至还有聊天或者会议的音视频。当初有一些产品曾经反对局部性能了。主动依据文档内容生成动态、动图、视频等内容:当初曾经midjourney 曾经能够依据形容信息主动生成图片了。如果咱们的文档写得不够具体,AGI 能够通过对效力平台的学习,补充文档,甚至能够增加动图或者视频来辅助了解文档内容。工作的高效治理和解决:当效力平台把本人能力通过API 给 AGI 后,咱们就能够通过语音或者以文字沟通的模式高效治理咱们那的工作。比方对着 AGI 机器人说:“列出我当初进行中的工作有哪些,请敞开工作2,备注已实现,给小明发个告诉。” 这样AGI就成了咱们的集体工作助理。AGI+代码编写、调试、审查主动代码生成:AGI能够依据用户通过语音或文本形容的程序逻辑,主动生成代码框架或大部分残缺代码。节俭手动编码的工夫,特地实用于比拟规定和结构化的业务逻辑。智能代码补全:AGI能够分析程序上下文和开发者的用意,智能举荐能够补充的API、模块、变量名等,辅助开发者编码。代码纠错和重构:AGI能够实时剖析开发者编写的代码,检测潜在的谬误、不标准之处以及能够优化的中央,并提出批改倡议。晚期发现并修复问题,升高前期调试的难度。AGI也能够依据最佳实际,主动优化和重构已有代码。主动生成文档和正文:AGI能够依据程序逻辑主动生成代码正文和文档,节俭手动编写文档的工作量,并保障文档的准确性和实时性。单元测试用例的生成和补充:对现有代码,补足单元测试用例;对新代码,主动生成单元测试用例。人工评审代码准入:对于须要做CodeReview 的代码(比方架构上的思考),能够通过 AGI 二次扫描解决问题后,再进行人工CR。AGI+Testing除了文档协同和代码编写智能辅助,我感觉测试方向会是AGI的另外一个用武之地,且大有可为。 单元测试:补充单元测试用例曾经不是什么新鲜事了,咱们还能够让AGI主动执行代码,依据代码测试覆盖率的后果补充单元测试。这就更近一步了。 API测试:依据swagger 文档,或者 postman 主动扫描扫描所有 API,生成测试用例,而后每个API接口都调用一遍生成报告。 性能测试:之前咱们的很多性能测试都是通过制作高负载测试其零碎的性能,有了AGI之后,因为它理解咱们零碎的整体架构,数据库表构造,调用链条,能够有助于咱们结构出无效的性能测试用例和流量数据。 功能测试:因为AGI能够通过文档晓得咱们要验收的性能,所以能够让其对比产品需要文档进行性能验收测试。 UI 自动化测试和验收:之前互联网行业UI 的自动化测试不太风行,次要起因是互联网行业页面变动快和UI自动化测试老本高。而有了 AGI之后,AGI就能够主动生成测试脚本来进行自动化测试。同时如果产品需要文档中含有设计师的设计稿,甚至能够让 AGI 把性能页面和设计稿进行比对,升高了设计师走查的工作量,进步了工作效率。 除了下面,还有平安测试、可拜访测试、混沌测试等非功能性测试,AGI都能够帮忙咱们。之前测试条件比较复杂、人力执行测试老本高的工作都能够统统交给 AGI,让它来帮咱们执行。 AGI+可观测性可观测性(monitor+logging+alarm+tracing)和AIOps 咱们能够先通过可观测性零碎的建设,收集零碎的各种数据,而后通过 AGI 加持的 AIOps 剖析和解决这些大量的经营数据。如果 AGI 能通过经营数据反推服务、代码、需要中存在的问题和纰漏,将会大大缩短 idea-code-data-feedback 这个反馈的链路,进步产研交付效率,bug修复效率,进步零碎的稳定性和运维效率。 AGI+ 外部问答知识库和客户服务目前的企业智能客服还是比拟高级的,个别流程是员工发动聊天询问问题,智能客服会依据关键字给出一个或多个备选解决办法,有的还会给出相干文档链接,如果仍然不能解决问题,员工能够通过智能客服转人工服务。 有了 AGI 当前,咱们就能够利用公司外部数据和知识库的信息训练一个专门服务企业外部员工的 AGI,这样员工就不再须要简单检索,只需像与真人对话一样提出问题就能够了。 因为 AGI 还具备语言翻译的性能,你能够用英文询问问题,我能够通过中文答复,AGI从中主动翻译,这样能够进步跨语言的交换效率,缩小多语言客服反对人员的数量,升高企业经营老本。 ...

May 11, 2023 · 1 min · jiezi

关于devops:3-步集成-Terraform-极狐GitLab-CI-实现基础设施自动化管理

本文来自:极狐GitLab 开发者社区作者:KaliArch利用极狐GitLab CI 实现基础设施编排自动化后,用户就能够应用极狐GitLab 进行基础设施治理:提交基础设施变更后,会触发 MR 进行极狐GitLab CI 流水线执行,从而实现基础设施 DevOps 流程。 Terraform + 极狐GitLab CI 架构解析流程图 流程详解开发或运维人员编写基于 Terraform 的指标云资源清单文件,同时我的项目内治理极狐GitLab CI 流程,在 K8s 不同 NS 下注册有对应的 Runner,在不同分支下能够触发不同 NS 下的 CI 流程: 开发或运维人员提交代码;部署在对应名称空间下的 Runner 执行流程,创立运行单个 Stage 的 Pod 来运行 Terraform 对应命令,例如 init/fmt/play/apply 等;如果要对云上资源进行变更,批改代码,再次提交 MR,触发更新流水线;如果须要销毁,依据 CI 文件配置提交 Build 为 Destroy,触发云上销毁动作。Terraform + 极狐GitLab CI 预置条件极狐GitLab 服务器;注册有我的项目的极狐GitLab Runner;K8s 集群;腾讯云 AK 账号。开启极狐GitLab CI + Terraform 实战极狐GitLab CI 配置.gitlab.yamlvariables:# PHASE: BUILD|DESTROYPHASE: DESTROY#  PROXY: http://squiduser:xxzx789@43.134.199.162:3128#  PROXY: http://squiduser:xxzx789@43.154.230.17:3128REGION: "ap-guangzhou"PLAN_JSON: plan.jsonBACKEND_CONF: "backend_oss.conf"before_script:#  - apk add --no-cache curl git jq- apk add --no-cache jq- export http_proxy=${SQUID_PROXY}- export https_proxy=${SQUID_PROXY}- export TENCENTCLOUD_SECRET_KEY=${TENCENTCLOUD_SECRET_KEY}- export TENCENTCLOUD_SECRET_ID=${TENCENTCLOUD_SECRET_ID}- export TF_REGISTRY_CLIENT_TIMEOUT=120000- export CHECKPOINT_TIMEOUT=500000- export TF_REGISTRY_DISCOVERY_RETRY=5- alias convert_report="jq -r '([.resource_changes[]?.change.actions?]|flatten)|{\"create\":(map(select(.==\"create\"))|length),\"update\":(map(select(.==\"update\"))|length),\"delete\":(map(select(.==\"delete\"))|length)}'"# 配置缓存cache:  paths:    - ${CI_PROJECT_DIR}/.terraform/*stages:  - init  - validate  - plan  - deployInit:  image:    name: hashicorp/terraform:0.14.0    entrypoint: [""]  stage: init  retry:    max: 2    when:      - script_failure  tags:    - gitlab-runner-k8s-new  script:    - terraform version    - terraform init -backend-config=${BACKEND_CONF}  only:    - devValidate:  image:    name: hashicorp/terraform:0.14.0    entrypoint: [""]  stage: validate  tags:    - gitlab-runner-k8s-new  retry: 2  script:    - terraform init -backend-config=${BACKEND_CONF}    - terraform validate    - terraform fmt -check -recursive || echo 0  cache:    paths:      - ${CI_PROJECT_DIR}/.terraform/*    policy: pull  allow_failure: truePlan:  image:    name: hashicorp/terraform:0.14.0    entrypoint: [""]  stage: plan  retry: 2  tags:    - gitlab-runner-k8s-new  artifacts:    paths:      - plan.bin      - app_config.zip    expire_in: 2 week  script:    - terraform init -backend-config=${BACKEND_CONF}    - terraform plan -input=false -out=plan.bin -var region=${REGION}    - terraform show --json "plan.bin" | convert_report > ${PLAN_JSON}- cat ${PLAN_JSON}only:variables:- $PHASE == "BUILD"Apply:image:name: hashicorp/terraform:0.14.0entrypoint: [""]  when: manualstage: deployretry: 2tags:- gitlab-runner-k8s-newscript:- terraform init -backend-config=${BACKEND_CONF}- terraform apply -auto-approve -input=false plan.binonly:variables:- $PHASE == "BUILD"environment:name: snunvDestroy:image:name: hashicorp/terraform:0.14.0entrypoint: [""]  stage: deployretry: 2tags:- gitlab-runner-k8s-newscript:- terraform init -backend-config=${BACKEND_CONF}- terraform destroy -auto-approve -var region=${REGION}only:variables:- $PHASE == "DESTROY"环境配置利用极狐GitLab CI/CD 的 Environment 进行环境治理。 Terraform 资源provider "tencentcloud" {  region = var.region}terraform {  required_providers {    tencentcloud = {      source  = "registry.terraform.io/tencentcloudstack/tencentcloud"      version = ">=1.61.5"    }  }  backend "cos" {}}# 输出变量variable "region" {  type = string}# 再次仅为一个查问示例data "tencentcloud_instances" "cvm" {}# 输入output "result" {  value = {    cvm_result = { for k, v in data.tencentcloud_instances.cvm : k => v },    count      = data.tencentcloud_instances.cvm.instance_list[*]  }}为了 Terraform 后端 Backend 平安,将其存储为独自文件,可在不同分支或环境进行批改。 ...

May 11, 2023 · 1 min · jiezi

关于devops:devops|中小公司效率为王没必要度量

之前写过一篇文章《devops|中小公司不要做研发效力度量》,次要是从基础设施方向思考,因为很多条件都不具备,贸然高投入去做研发效力度量可能达不到咱们的预期成果,给出的倡议是先做好当下打好根底。明天想到一个好例子,能够类比下。 两个人大家庭1)人少2)支出清晰3)收入清晰,买了什么货色,花了多少钱,该不该花,一眼清4)如果违心,两个人买个记账本记下来就能够,或者找个记账软件5)每天记账也是很耗时的。本有美妙的生存不去享受,还要每天给本人上发条,每天都记账,也很悲催6)如果想通过记账来节约开支,根本不可能。因为两个人的生存的收入大部分都是必须的;如果两个人的生存却把钱用到了很多不该用的中央,却想通过记账来发现问题、解决问题、改良财务状况,这是基本不可能的。比方之前每周都去趟低档餐厅,「当初」「忽然」发现这块收入很高?而后就不去了?7)活在当下,花钱的时候多想想,比预先再想怎么节约更间接。中小公司1)人不多2)账务清晰3)每件事件该不该做,该不该投入资源,投入多少资源,当初都磋商过做出的决策。4)如果真要看下投入产出比ROI,简略对公司的人力、资源和我的项目做个盘点就能够。5)人力部门算下每个部门的人力投入老本;业务部门汇总下当初正在进行的我的项目,把两边的数据放到一起看一下就能大略晓得状况。6)不要用战术上的怠惰,来覆盖策略上的懈怠。多思考业务,不自觉投入,谋定而后动,知止而有得。当然如果你做研发效力度量是另有目标,想做些其它的事件。比方想通过家庭记账限度老公花钱,本人轻易花;比方虚报账目,建设小金库;本已同心协力,想通过记账来摸清对方底细,本人留一手。这些状况均不在此列探讨。 本文总结中小公司效率为王,没必要度量。做好当初,活在当下,谋定而后动就是最高效的。另外就是周末看了一篇讲研发效力度量的微小的帖子,几万字。看得我头疼,所以想通过一些简略的办法来了解这件事。 我的相干文章devops|中小公司不要做研发效力度量infra | devops工具链基建建设评估规范DevOps | 互联网、软件公司基础设施建设(基建)哪家强?DevOps | 研发效力价值如何掂量DevOps|研发效力不是老板工程,是开发者服务 感激点赞、转载关注我,理解研发效力倒退动向

April 26, 2023 · 1 min · jiezi

关于devops:从-Dev-和-Ops-视角出发聊聊-DevSecOps-的-What-Why-How

近日,极小狐和 TA 的敌人们相聚上海,发展了一场技术 Meetup,从 DevSecOps 的 What、Why、How 登程,通过分享实在利用案例,与参会者交换 DevSecOps 的实际过程和落地教训。 本文整顿自极狐(GitLab) 资深云原生架构师郭旭东在会上分享的内容,从 Dev 视角和 Ops 视角聊了聊企业引入 DevSecOps 能解决什么问题,并基于极狐GitLab 的实践经验,分享 DevSecOps 如何落地。Enjoy~ DevSecOps 是笼罩软件开全生命周期的一种平安防护体系,也是一种集泛滥平安伎俩于一体的办法。 “工具是伎俩,不是目标” 这是咱们一再申明的观点。DevSecOps 最终目标是为了尽早的发现、开掘软件中潜在的平安问题,以直观的形式出现给软件开发生命周期上的相干人员,包含 Dev、Ops、Sec、QA 等。 为什么须要 DevSecOps ?Dev 视角 Dev(研发人员)不小心写了 bug,造成安全漏洞,给研发人员和公司都会带来损失。 为了防止这样的 “喜剧”,研发心愿在开发过程中,就进行充沛的平安验证,「平安左移」由此而生。 相较于传统「右侧防护」的平安模式,「平安左移」把各种平安实际内建到软件开发的各个要害节点之中,通过尽早引入平安实际以及疾速获取平安反馈的形式,从问题的源头着手防止平安问题的产生。 而 DevSecOps 是平安左移的最佳实际:DevSecOps 的要害是将安全性嵌入到整个软件开发生命周期中,从而确保应用程序的安全性可能失去继续一直地改良和保护。 施行 DevSecOps,Dev 会面临什么变动? 一方面,是须要学习新知: 平安常识:例如常见的攻打类型、安全漏洞、安全措施等;工具和技术:例如继续集成和继续交付工具、自动化测试工具、容器化技术等;测试方法和流程:例如自动化测试、集成测试、平安测试等;DevOps 文化和实际:例如麻利开发、继续集成和交付、自动化和可观测性等。另一方面,可能也会面临一些心智累赘: 压力:例如须要疾速响应问题、继续改良工作流程等;复杂性:可能会减少肯定的复杂性,例如须要对多个工具和技术进行整合、须要解决多个团队的反馈等;变动:例如须要扭转工作形式、角色和责任等;沟通和合作:须要更频繁地进行沟通和合作,须要团队成员具备良好的沟通和合作能力。Ops 视角 从 Ops 视角看,DevSecOps 的关键在于:确保应用程序的安全性失去继续一直地监控、检测和响应,以爱护应用程序在生产环境中的安全性和稳定性。 施行 DevSecOps,Ops 面临什么变动? 一方面,将更加关怀自动化和标准化: 自动化:DevSecOps 实际中的许多工作都能够通过自动化来实现,例如构建、测试、部署、监控和复原等。通过自动化,能够实现更疾速、更牢靠的交付流程,缩小人为谬误和故障,并进步生产效率和品质;标准化:标准化能够帮忙团队建设对立的流程和标准,以确保开发、测试、部署和运维过程的一致性和可重复性,帮忙团队缩小谬误和危险,提高效率和品质;流程优化:自动化和标准化能够帮忙团队优化整个交付流程,从而更疾速、更牢靠地交付高质量的软件和服务。流程优化能够使团队更加麻利和翻新,更好地适应疾速变动的业务需要。另一方面,须要更加关注平安和合规性: 平安:在 DevSecOps 中,平安是开发和交付流程中必须思考的关键因素;合规:开发和交付过程必须合乎实用的法规、规范和政策;平安与合规的交融:在 DevSecOps 中,平安和合规应该融入到整个开发和交付生命周期中,而不是独自的流程,以确保软件和服务在设计和交付时满足平安和合规规范。实际 DevSecOps 的难点与挑战难点 1:文化改革DevSecOps 要求不同团队之间更严密的合作,这须要突破传统的部门隔离和沟通壁垒,须要进行文化上的改革,晋升团队之间的信赖和合作能力。 难点 2:工具品种繁多咱们让 ChatGPT 帮忙列举了一些 DevSecOps 工具,可见之多。 ...

April 20, 2023 · 1 min · jiezi

关于devops:devops|中小公司不要做研发效能度量

我特地恶感那些不顾公司现状一上来就想要做研发效力度量的人,尤其是想把研发效力度量当成锤子到处去敲打螺丝钉的人。 没几个人的小公司上来就做研发效力度量,就如同普通人一上来间接问媒婆怎么能娶到迪丽热巴。解决办法无非把大象装冰箱里的那三步。套用一下,公司想要做好研发效力度量也有规范的三步:长时间对研发效力业务投入,建设好研发效力工具链,做好效力度量。事实是咱们很多公司卡在了第一步上。咱们能够边做研发效力平台边做效力度量,但不能啥也没有靠嘴造出来的效力度量,否则容易高低相互糊弄。 长时间对研发效力业务投入欠缺研发效力工具链建设做好研发效力度量和一些老板交换,常常被问到公司当初想做研发效力度量,要做什么指标,怎么做,多长时间能实现。做啥研发效力度量啊,先保障公司三年不倒再说。产研运同学在脉脉上喷公司的基建都喷出火星子了,还做啥研发效力度量。我倡议不把这些小伙伴火上眉毛的事件解决,就不要做研发效力度量。 很多人想要些数据的情绪是能够了解的,毕竟终日拍脑袋做决定太假大空了,本人心里都发毛。如果能有一些产研运的数据,而后再拍脑袋也会容易些,所以一上来就想做研发效力度量。然而有时候,咱们低估了做这件事的难度,高估了做这件事的成果。 举个例子: 已经有家公司的CTO想做研发效力度量,找PMO来驱动做这件事件。然而通过摸底发现现状如下: 1)所有工作在 jira 中2)代码在 gitlab 中3)编译,构建,上线在公布零碎中。只能按分支公布,不反对按 commit 公布,公布时可抉择 jira 工作(非必须)4)PMO的小伙伴不晓得从哪里收集的,列举了各种度量指标,一个个问,这个指标是否能够出,怎么出,啥时候能失去。此时很多数据不具备真实性,零碎间无奈买通,须要人为校对、解决,指标不能主动获取。其实如果咱们站得角度高一些,应该坦诚地跟 CTO 去聊,咱们当初这种状况基本不适宜做效力度量,即使给出一份报表也是不实在的,无奈反馈理论产研运状况,如果再依据这个报表去做决策理论误差兴许还不如拍脑袋。后果「拿着尚方宝剑」的PMO要求限时、保质保量地要这么一份报表,且当前定时出。后果可想而知,从多个数据库中去比对工夫「攒」出的一份报告,几乎不忍直视。还节约了很多人力物力。 乔梁老师的《工程效率胜任力改善牵引指标体系》这篇文章(文末有链接)曾经对研发效力度量的事件进行了很好的论述,其中列出了19 个后果展现性指标,12 个维度的 50 个过程引导性指标,且在这篇文章的最初非常贴心地给出了「情谊提醒」: 度量有老本,而且不低当指标变成指标后,它就不再是好的指标指标最终都会被捉弄改良不应「唯数字论」明确研发效力度量的指标要想做好研发效力首先要明确做的目标是什么,是给管理层看统计数据,还是让中基层理解业务运行状况做决策。 很多数据一「均匀」就覆盖掉了「大多数」问题,且变得毫无意义不同团队,甚至同一团队的不同期间的效力都有所差别,通过简略几个数字未必能无效度量出一些度量报告很容易,难的是通过度量报告进行根因剖析,看到背地的问题;即使数字雷同,背地的理论状况也是千差万别最好的「研发效力度量报告」是团队负责人:他们晓得团队的效力,晓得团队的问题在哪里,团队哪里效力低,怎么能力改良之所以「忍耐」一些低效能低体现,是因为有「更高优的」工作或者有一些「难以诉说」的苦衷,这要靠好高鹜远深刻一线去挖掘。其次是每天工作在一线的同学,如果他们都不晓得效力低的起因,却想通过一些度量指标反馈进去,这是有悖常理的。怎么去解释好数字背地的情景也须要很大的投入。咱们来举个例子 生产环境上线成功率:每个计算周期服务进行上线胜利的次数/上线的总次数。这个指标能够体现出服务上线的品质。这个指标是否管用呢?是的,管用。然而如果一味的谋求指标的数值就会造成大家都不敢上线了,以前每天晚饭时间上线一次改成了只周四上一次线。对于一个性能正处在疾速迭代的产品,咱们更期待所有的性能能尽快推到用户的背后,收集用户的反馈,以便及时批改和加强。那么适度谋求这个指标对业务的倒退就是无害的。如果再加上一个上线次数的指标要求呢?也就说既要求上线次数多又要求上线成功率高。这个时候在没有更好的办法保障品质和效率的状况下,就会对团队造成很大压力,团队个别会要求减少人员投入,比方更多的开发和测试同学。如果研发和测试同学「必须」不能加,上线次数「必须」保障,上线成功率也「必须」保障,怎么办?典型的既要又要还要的情景。这个时候团队动作就会变得畸形了。产研运团队会要求排入迭代的需要个数升高,同时会呈现一些没必要的上线动作。一些可改可不改的需要排了进去,一些大的需要会拆分成一些改变特地小的需要独自上线。。。这样看似上线次数没变,每天都有货色上线,上线成功率进步了,且人数也没加,然而多了很多意义不大的上线操作且最初上线的有价值的性能还少了。有变更就会有危险,有危险就可能会对用户造成问题。一旦造成问题,业务负责人就得负责。典型的金玉其外败絮其中。- 本文小结 -在还没有长时间投入研发效力团队的时候,在研发效力工具链还没成型的时候,不要贸然做研发效力度量。研发效力度量也是须要老本的,而且是很高的老本。与其后期投入一个产出不高的工作,不如增强研发工具的建设,去反对产研运工作的研发,把研发效力团队的价值在业务的增长和反对保障中体现进去。 参考: 工程效率胜任力改善牵引指标体系infra | devops工具链基建建设评估规范DevOps | 研发效力价值如何掂量DevOps|研发效力不是老板工程,是开发者服务

April 13, 2023 · 1 min · jiezi

关于devops:如何在-DevOps-中进行-API-全生命周期管理

随着 DevOps 理念在中国企业当中的遍及和倒退,中国企业 DevOps 落地成熟度一直晋升,依据中国信通院的数据已有近 6 成企业向全生命周期治理迈进。 而在研发全生命周期治理之中,API 治理的位置愈发显得重要。随着 API 数量的大幅增长,也带来了新的 API 治理需要。 如何在 DevOps 工作流中进行 API 全生命周期治理,对我的项目研发来说具备重大意义。 1、DevOps 中 API 治理窘境在理论的 DevOps 工作流中,API 治理面临着以下 6 大方面的窘境:标准、合作、自动化品质、迭代、自动化。 窘境一:标准落地执行难因为团队中的 API 文档品质参差不齐,导致标准很难落地执行。起因在于公司有很多的研发我的项目和团队,不同的团队有不同的API治理习惯,尤其是罕用的 Swagger 形式的治理,很难进行对立的平台化治理。 针对这个窘境,能够通过对立的 API 治理平台标准文档的模板,疏导编写流程和习惯,也能够通过自动化文档管理工具来简化流程,进步管理效率。 窘境二:岗位合作难、信息沟通效率低在 DevOps 工具链中,每一个工具都会有不同的告诉音讯,导致重要信息吞没在繁冗的告诉中。其次是工作流程环节多、流程长,各岗位角色解决工作节奏不一,导致工作链上下游沟通效率低。 针对这个窘境,能够缩短流程环节,多启用自动化流程。同时制订精细化告诉规定,依据优先级提供差异化告诉款式。最初,再通过每日推送复盘音讯,梳理当日工作项和音讯告诉,避免脱漏。 窘境三:自动化测试体系搭建门槛高传统的自动化接口测试脚本须要用 Python 来编写,门槛高,老本高。又因纯手工编写,开发变动后还须对照文档二次调整接口的所有脚本。另外,自动化测试后期投入工夫多,筹备工作繁冗。 针对这个窘境,能够应用界面化的自动化测试工具,升高脚本编写门槛。还能够通过一站式 API 全生命周期治理平台,免去大量前期工作,进步自动化测试效率。 窘境四:API 生产品质和在线异样的发现、跟踪、解决流程过长当下,在后端的接口自测、前段的 MOCK 测试、冒烟测试、集成测试、异样监控这 5 个环节中都会应用到不同的工具,于是产生了跨工具之间对接简单、数据隔离,导致 API 生产品质单薄,以及大量反复工作。 能够通过一体化的 API 管理工具来买通不同环节的工作流,进步研发品质和效力。 窘境五:接口文档无奈跟踪迭代版本,回溯排查难度大传统的接口管理工具如 Swagger 没有接口批改记录,短少版本治理,无奈通过日志定位问题,无奈进行回滚和历史比照。另外团队也短少接口迭代打算,导致开发量和影响面剖析都难以评估。 接口文档作为研发我的项目的重要资产,应该对其变更进行盘点,包含提供接口文档的历史记录。能够通过一站式 API 全生命周期管理工具,提供我的项目级的接口版本治理和接口迭代打算,输入更加优质的接口文档,推动 DevOps 工作流的效率晋升。 窘境六:DevOps 工作流应用工具多 DevOps 作为宏观层面的研发治理思路,目前并没有大而全的工具,因而带来企业外部工具越积越多,数据流通阻滞,另外,传统接口管理工具性能也很繁多。 ...

April 13, 2023 · 2 min · jiezi

关于devops:devops工具链基建建设评价标准

之所以写这篇是因为有敌人私下让我欠缺下基建建设的规范和四个阶梯划分,而后让我肯定要把腾讯和百度加到基建建设的排名中(看热闹不嫌事大)。 基建infra建设四个考查维度1)工具链完整性:该有的工具是否都有了2)性能齐备性和易用性:工具该具备的性能是否都有了,是否容易应用3)反对和服务:是否有人继续地保护、反对和服务4)员工满意度:员工是否称心基建infra四个阶梯第一阶梯:具备齐备的工具链,提供方便的接入和反对服务,很快上手。在职员工「十分认可」公司的基建建设,到职员工十分「思念」「感叹」公司基建。第二阶梯:具备外围的工具链,提供了接入和反对服务,但须要肯定工作量能力应用。在职员工感觉「还能够」,到职员工很少「diss」。第三阶梯:工具链不残缺有所缺失,或者接入不便,保护、反对、服务反对不到位,或者比拟难用。在职员工感觉「繁琐」「又不是不能用」,到职员工「不称心」「diss工具」第四阶梯:工具链缺失重大,稳定性,可用性差,简直没有相应的反对和服务,全靠员工本人摸索。在职员工感觉「公司还有基建?」,到职员工感觉「太差」互联网公司基建排名有了考察点和规范,咱们就很容易把互联网公司对着规范排排坐。 阿里和美团相对的在第一阶梯,这里岂但有各种各样的工具,而且提供了不便的接入和服务,让你能够很快上手用起来。员工十分认可公司的基建建设。第二阶梯的工具链或者某方面有所缺失,但员工对工具的满意度还能够。第三阶梯的工具链建设有缺失,满意度差。比方京东的测试环境第四阶梯员工对公司的基建十分不满,比方 shopee的员工对 git 服务器卡顿的「愤恨」总结下来基建排名阿里(蚂蚁稍逊)>美团.........>滴滴>拼多多(Java侧)>京东科技>携程=去哪儿.....>字节>京东商城......>Oppo>Shopee,网易,B站 至于腾讯和百度,这回就不必我给排名了吧。通过下面的规范,你感觉腾讯和百度应该放到哪一阶梯呢?也欢送各位把公司加进去并给出相应的排名。 我的其余原创文章DevOps | 互联网、软件公司基础设施建设(基建)哪家强?DevOps | 研发效力价值如何掂量DevOps|研发效力不是老板工程,是开发者服务研发效力负责人/研发效力1号位|DevOps负责人研发效力DevOps举荐书单

April 12, 2023 · 1 min · jiezi

关于devops:研发效能-DevOps如何改变游戏公司工作方式

如果你是游戏开发者,那么在过来几年里,你可能会感觉有人给了你一把双刃剑。 整个行业一直蓬勃发展,但玩家的预期值也越来越高。玩家们总是心愿游戏体验可能更快、更实在、更具创造性。此外,他们还心愿可能定期推出新的游戏和更新。 基于这种文化背景建设起来的行业,总是须要一直解决各种难题,这就是游戏开发人员的劫难源头,或者说,至多是他们产生职业倦怠的次要起因。 局部游戏公司曾经踊跃采取了许多措施,心愿可能打消职业倦怠。以拳头游戏公司为例,这家公司会在一段忙碌的工作周期之后,为所有员工放一个星期的假,让他们劳动、放松。 一周的假期尽管不错,但这只是开始。 如果既心愿按估算如期交付更优质的产品,同时又打算打消职业倦怠,做好员工关心工作,那么游戏行业必须制订久远的解决方案。 这就是DevOps受青眼的起因。 游戏开发过程中,DevOps是否是解决开发人员职业倦怠的良药?尽管有时游戏开发过于简单,无奈引入DevOps,但从很多方面来看,它都是游戏开发零碎和流程的完满抉择。DevOps帮忙你专一于解决重要的事务。在游戏开发过程中,DevOps的所有主旨就是缩小节约,尽可能进步自动化程度,同时汲取过来的经验教训踊跃调整工作过程。剔除所有不必要的事物,使你的团队能够专一于构建更优质的游戏。 围绕迭代开发构建。DevOps的外围是继续交付和继续学习。你一直地构建软件,公布软件,收集反馈意见。而后又从新开始——只有到了这个时候,你能力依据各种谬误、客户反馈或投诉以及上次开发过程中影响开发流程的各种问题,调整你所采纳的办法。对游戏开发来说,整个流程十分完满。每公布一个补丁,投放一个新的性能,或推出新的降级,游戏就会变得更快、更有效率。就像是职业生涯中的New Game Plus(新游戏增强版)。 易于监测工作业绩。没人喜爱仓促地推出产品。游戏公司须要寻找更好的办法,辨认职业倦怠迹象,同时在开发初期确定游戏中潜在的问题。有了DevOps,你能够在开发过程中记录和监测尽可能多的信息,特地是CPU负载RAM调配、网络流量统计和内存使用率等信息。这样能够缩小各种意外,同时还能依据游戏公司和DevOps的指标体系,实时地理解业绩体现。 弹性伸缩空间大。玩家最无奈承受的游戏毛病就是提早。如果云空间使用率能够主动调整,那么当大量用户同时拜访服务器时,你也可能轻松应答,防止因配置了过多云贮存空间,导致在闲暇工夫内产生大量节约。 零停机工夫。无需多言。当你部署了多个环境,并在不影响玩家的前提下更新游戏时,你能够让玩家们自行决定何时装置更新并重启游戏。另外,即使更新周期很紧,你也能够加重团队的压力;不须要停机,你能够在更新或补丁准备就绪后再公布。 更平安的工作形式。正是出于这样的起因,宝可梦公司在公布《精灵宝可梦Go》游戏时,开始更加依赖DevOps。这家公司手握数百万儿童的数据,必须在保障数据安全的同时,扩大或缩减其基础架构。如果没有弱小、牢靠的DevOps开发技术以及反对DevOps的云基础架构,《精灵宝可梦Go》相对没法在保障客户数据安全的前提下,增长得如此之快。 继续集成 (CI) 让大型团队和我的项目之间的沟通更顺畅。当你一次性集成多个小块代码时,在代码块存入代码库时就立刻测试新代码、筛选出潜在问题,工作会变得容易得多。团队中的任何成员都能够进入CI流程的任何阶段来查看进度状况,而不用定期梳理查看大量数据。 游戏开发过程中DevOps的五大强劲趋势那么,在游戏开发过程中,你须要从哪里开始应用DevOps呢?个别在这种状况下,随大流不会出错,而且许多DevOps趋势曾经被业内游戏公司所采纳。 云游戏开发 玩家心愿游戏速度越来越快,细节越来越明确,沉迷式体验越来越好,然而每次更新过后,游戏都会越来越低廉,玩家们必须配置更好的硬件,他们要承当的老本压力也越来越大。要满足玩家们的需要,游戏就必须反对一般的游戏机,不然就会错失大量潜在客户。 将游戏解决从玩家的硬件端转移到服务器端,能够突破这样的僵局,为游戏留出增长空间。事实上,一些游戏公司曾经开始应用云计算,将游戏开发和游戏玩法抬升到一个新的高度。 以育碧游戏为例,作为《刺客信条》系列游戏的开发者,这家公司始终以其深度、简单的虚拟世界而闻名,然而当初,这家公司曾经开始应用云计算,迈向更远的路线。最新的《刺客信条》系列游戏不仅仅为玩家带来沉迷式的历史体验,还利用云计算的力量,促成人工智能驱动的游戏环境一直演变和倒退。 继续交付和迭代显然就是DevOps的外围,而DevOps办法能够让云部署变得更容易。通过测量、继续学习和自动化等DevOps实际,你能够防止许多问题,例如网络问题和低提早等,确保游戏开发者顺利完成云部署。 无服务器架构 无服务器计算实质上就是将搭建架构的责任从物理服务器转移到AWS Amplify或Azure等第三方架构供应商身上。 一旦你深刻理解无服务器架构,你就会明确为什么DevOps在游戏开发中如此受欢迎。 首先,DevOps反对超级弹性伸缩。无需专门指派开发人员监测基础架构应用状况并进行手动调整,你的后端供应商能够依据须要主动扩大或缩减基础架构。也就是说,开发人员能够专一于编写和部署代码、微调流程、确保按计划实现目标,不用放心底层的所有架构。 然而,最要害的是,无服务器架构真正地减速了游戏开发的整个过程。当你不用放心后端基础架构时,你能够在须要时增加和批改代码,以公布新个性,修复谬误。 在游戏开发这种极其考究时效期的行业里,无服务器架构就成了价值连城。如果有什么货色可能保障让开发人员放松下来,打消职业倦怠,那它必定就是无服务器架构。 风行的DevOps工具 问题是:DevOps不是软件,也不是繁多的流动。它是一套残缺的工作形式,是你的团队所采纳的全副流程和理念的组合。 当你领有适合的工具后,你就能轻松地遵循DevOps的流程和理念。 所以,许多DevOps工具当初曾经成为次要的游戏开发工具。 如果你心愿在较短的周期内公布产品,并且可能同时解决各种我的项目的公布、补丁和更新,那么你就须要应用工具,在生产周期内尽可能提高效率。 对于游戏开发过程中的DevOps,工具有: Perforce Helix Core,用于实现洁净、简略的版本控制,让变更监测、测试运行和谬误修复变得更容易。当初,Perforce曾经成为微软新Azure游戏开发虚拟机中一个“根本工具”(根本工具还包含Incredibuild以及其余许多解决方案),将来或者会成为游戏开发合作的必选工具。让咱们刮目相待。Incredibuild,用于减速构建缓存和优化计算资源,放慢开发周期,减少迭代频率。Jenkins或企业版Jenkins——CloudBees,用于实现自动化继续集成,实用于各种编程语言。容器 容器自身就能扭转游戏开发。 利用容器代码、运行工夫、零碎库、零碎工具和设置压缩软件包,你能够在简直所有操作系统中,更轻松地以虚构的形式运行软件。这意味着,不同开发人员之间能够实现更轻松的合作,最重要的是,以更快的速度进行跨控制台开发,且产生的谬误更少。 像Docker这样的优质容器注册表,能够在基于Linux和Windows的应用程序上运行,从而轻松构建反对各种环境的软件。集成JFrog容器注册表和Helm chart存储库,能够进行Kubernetes部署。甚至,集成artifactory容器注册器,还能给予开发人员更多的拜访和权限管制。 将容器化与DevOps实际相结合,你还能开启一个全新的继续开发模式。你能够: 在须要时启动和禁用容器。启动容器,用来测试游戏中的元素,而后回收容器。所有操作均在统一且可复制的环境中实现。依照“构建一次,部署多个”的策略,以更快的速度实现部署,尽可能减少故障。制品库中存储的‘映像’有助于轻松地疾速创立大量雷同的容器。这些容器能够疾速部署到不同的环境中,在各种最优质、最牢靠的制品中,你能够轻松地利用更多劣势。测试自动化 构建游戏,就是把各行各业的大量专业人才汇集在一起,让他们发明出一个连贯晦涩的作品。就像是把米开朗基罗、帕瓦罗蒂、莎士比亚和毕加索招集在一起,请他们发明一件艺术杰作。不过,数以百万计的人员会一直通过窗口询问他们是否实现工作。 如果你是游戏开发者,你必定晓得全盘测试和频繁测试的重要意义。所以您须要在游戏开发过程中应用DevOps,DevOps应该是工作过程中的一个重要组成部分。 但说起来容易,做起来难。现实状况下,你只须要在可能的控制台和环境下,联合各种可能的消费者行为,定期测试各局部代码。然而,手动运行所有测试,简直是不可能的,特地是大规模测试。 单元测试——利用专门的程序测试其余程序的性能,通过自动化解决测试过程中随同的局部简略、重复性工作,比方创立角色、启动游戏或执行多数根本命令时,能够加重员工的累赘。 自动化测试面对更简单的测试工作没有手动测试这么好,然而许多游戏公司发现,即使只是剔除一些重复性的小工作,就能够大大缓解开发人员的职业倦怠。 DevOps是否真的扭转了游戏?DevOps并没有齐全掌控整个游戏开发行业,至多当初还没有。 这个行业充斥简单的流程,各种优先事项互相抵触,员工接受着微小的交付压力,导致一些游戏公司不得不苦苦挣扎,寻找彻底转变其工作形式的机会。 很显著地,当游戏公司找到机会投入新工具并采纳DevOps流程后,就会产生微小的影响。 最重要的是,这种影响不仅仅是确立更高的底线,或者创立更好用的执行套件。受DevOps影响最大的群体,往往是游戏公司最关怀的两个群体:开发人员和客户。 作者:Joseph Sibony,Incredibuild高级内容经理。他一辈子都在跟技术打交道,不论是硬件、软件,还是二者之间的联合。他从事数据迷信和网络安全方面的工作,撰写了大量对于技术与社会相结合的文章。 文章起源:https://www.incredibuild.cn/blog/youxikaifaguochengzhongdevop...

April 3, 2023 · 1 min · jiezi

关于devops:DevOps|研发效能价值如何衡量

当初很多公司都在做或者打算做研发效力,也晓得研发效力工作很重要,能进步产研运同学的协同效率,进步员工的工作效率和品质,进步业务交付效率和交付品质,然而价值有多大?效率又有多高呢?因为不容易说分明,所以常常碰到一些质疑和灵魂拷问。 如何掂量研发效力的成果?如何掂量研发效力的作用?如何说分明研发效力工作的价值?研发效力是做啥的?有啥用?有多大用?研发效力定义之前我给过研发效力的定义,然而随着这个畛域的倒退,大家越来越重视「开发者体验」,因为这项工作太重要了,对员工的工作效率确实影响很大。之前咱们做研发效力平台的时候就特地重视开发者体验,但对于有些公司还停留在工具有无的阶段,临时留神不到这块。所以这次我对研发效力的定义进行了优化,想以此引起大家对这块的留神,促成这块的倒退,造成共识。研发效力定义如下: 研发效力是一个组织高效交付产品的能力,以及围绕进步这一能力所建设起来的由标准、流程、工具、度量体系、实际等组成的系统工程体系。指标是优化开发者体验,夯实产品研发经营基础设施和赋能组织继续高质高效地交付产品价值。研发效力次要工作标准制订:制订产研运协同的标准流程梳理:梳理产研运协同的流程平台建设:建设反对产研运协同的根底平台平台经营和服务:对产研运提供服务,并进行平台经营效力度量:对产研运协同进行效力度量,剖析存在的问题并推动改良和优化研发效力工作指标细分标准制订和技术治理 梳理公司技术现状、制订技术治理方向协调制订技术选型、研发流程等技术类标准解决公司业务倒退过程中遇到的共性问题和技术挑战为不同业务场景提供全面的技术解决方案进行规章制度、标准、平台应用的宣传、培训、布道、配套工具推广等推动建设和优化产研运合作流程 梳理和优化产研运之间合作的流程推动产研运高效合作梳理、宣导和推广工程最佳实际研发效力平台建设 把最佳实际固化到平台,进行研发效力平台建设保障效力平台的稳定性、可用性效力平台性能齐备的同时放弃高度易用高效率实现效力平台上的高频操作研发效力平台经营和服务 及时响应研发效力平台用户的日常诉求,高效解决用户问题及时收集、梳理和提炼用户的诉求,进行痛点剖析通过产品经营、内容经营、流动经营、用户经营,让用户更多地理解咱们的平台,,让平台「有人用、会用、善用」研发效力度量 梳理、计算、展现和剖析掂量端到端尽早尽快交付效率的指标梳理、计算、展现和剖析掂量端到端高质量交付的指标梳理、计算、展现和剖析掂量卓越工程能力、继续交付能力的指标通过研发效力度量发现产研运效力问题,推动组织解决、改良和优化研发效力价值说分明了研发效力的具体工作,是不是就很容易说分明研发效力的价值了?不是的。讲清楚了研发效力的具体工作,只是让大家理解了研发效力是什么,具体做什么,这对一线同学很容易讲清楚,然而对于往上+1/+2的领导来说还不是很容易get 到点子上,你讲了这么多,在他们看来是抓不到点子上。因为对于公司来说,团队带来的价值无非两件事,要么支出,要么老本,简略点说你给公司带来多少支出,或者你节约了多少老本。 说价值就要提支出和老本,但这对研发效力却不是一件容易说分明的事件。为什么业务的价值容易讲清楚?我用多少人开发的性能给公司带来多少利润,这是非常容易掂量的,只有每个月让财务出个数据就好。对于大多数公司来说,1)研发效力团队不对外,也就是无奈间接给公司发明支出。2)研发效力工作涉及面广,见效慢,须要长期投入,建设初期很难算清帮公司省了多少钱,甚至还要有肯定的人力老本收入。 那怎么能力讲清楚研发效力的价值呢?我感觉能够通过间接支出、节约老本、开发者体验和业务品质晋升四个方面来讲: 研发效力带来的支出研发效力团队人均反对公司员工的数量、趋势研发效力团队反对产研运团队的数量、趋势研发效力团队反对产研运团队外的业务团队数量、趋势研发效力节约的老本员工、团队做与之前同样的事件,效率进步的数据采纳新技术节俭了资源的投入,或等同资源反对了更多的业务倒退研发效力进步了开发者体验效力平台给用户带来的开发者体验,比方业务对接的效率效力平台用户 nps 评估效力平台经营客服的响应速度和反对品质业务方对研发效力团队、平台的用户访谈评估研发效力带来的业务效率和品质整体晋升业务的整体端到端交付效率,比方需要交付周期、吞吐量业务的整体品质进步,比方代码扫描高优问题解决趋势,上线成功率,回滚率继续交付能力,比方代码提交到部署实现的工夫,服务构建速度、频率和修复时长下面只是给出一些可参考的方面。在公司具体落地施行时,还是要捕风捉影地以业务为纲,服务好公司业务部门,以做产品的高标准要求本人,服务好产研运团队,同时找到适合的数据来反馈咱们的工作价值。 本文小结用一两句话给+1/+2领导讲清楚研发效力的价值是十分不容易的,尤其是团队建设初期,没数据,没抓手,没背书,可见的只是人力物力的投入。领导也是晓得研发效力是必须要做的,只不过什么时候做、做到什么水平、实现门路不是很确定,尤其是当还能够通过加资源(人力和物力)放弃业务增长的时候。此时我就须要通过一些可见的数据、指标和图表,多方面地展现出公司研发效力整体的情况、可改良点和未来的成果,让他对研发效力的业务更有体感和了解,让他明确研发效力工作的价值和团队的价值。 我的其余文章 DevOps|研发效力不是老板工程,是开发者服务研发效力之技术治理研发效力之产品经营什么是研发效力?研发效力定义及外围价值二三线互联网公司怎么做好研发效力 scmroad 次要关注畛域 { 研发效力、研发工具链、继续交付、DevOps、效力度量、微服务治理、容器、云原生},感激订阅。

March 30, 2023 · 1 min · jiezi

关于devops:DevOps-在未来将如何演进丨行业观察

自2007年 DevOps 这一概念推出以来,越来越多企业开始将开发和运维团队联合在一起,以放慢部署速度,进步软件开发生命周期的效率和合作。然而,诸多因素都会对 DevOps 是否胜利产生影响,例如组织规模、文化和施行打算等。  随着零碎愈发简单,企业正在寻找新的办法来加重开发人员的累赘,同时减速软件公布以放弃市场竞争力。随着 DevOps 相干技术和工具的成熟,IT 行业开始将注意力集中到 DevOps 的将来,以及企业自身是否筹备好将 DevOps 向平台工程的方向倒退。  DevOps 已死?答案是否定的。相同,DevOps 正随着组织的倒退而一直演进。  在最近的一场 CNCF 网络研讨会上,Mallory Haigh,Humanitec 客户胜利总监,提到 DevOps 往往是误会和误用的受害者。企业偏向于简略粗犷地招聘一个“DevOps 工程师”,而不违心从团队文化层面上采纳 DevOps 准则,因而在一些组织中 DevOps 的实际失败了。  Haigh 认为,DevOps 的外围“You Build It, You Run It”曾经消失,转而开始进入第二阶段,这一阶段的重点是反对和参加。因而IT团队能够在他们基础设施和云原生环境中以可继续的形式成长。  企业在继续减速倒退,许多人则感触到了来自KPI的压力,要求他们更麻利、疾速地交付代码,但以后的架构无奈接受这样的增长,进而导致开发人员不顾用户体验,而一味谋求疾速交付。  TechTarget 企业策略组(ESG)资深分析师,Paul Nashawaty提到:因而,企业正在摸索“左移”的策略,不仅仅是平安左移,而是将 DevOps 性能都左移到工程中。采纳 DevOps 更成熟的企业甚至开始转向平台工程。  平台工程的作用平台工程通过创立可复用的、自助服务的平台来晋升开发者体验和软件交付速度。这能够帮忙开发者回归到他们最善于的工作而不是被琐碎的细节缠身。Haigh 认为平台工程使IT团队可能以负责任和可继续的形式来践行“You build it and you run it”的准则。  平台工程师所创立和保护的工具和工作流程可能帮忙开发人员疾速且高效地推送代码。这解决了长久以来横亘在开发人员之中的问题——愈发简单的零碎、架构使得他们陷入无穷尽的重复性工作中。  Humanitec 的钻研显示,因为零碎复杂性减少,25%的开发人员将工夫破费在利用运维上。平台工程将会通过自动化来解决这类琐碎问题,进而升高开发人员的职业倦怠。  平台工程创立的规范框架应该笼罩应用程序的整个生命周期并为开发人员提供软件开发所需的所有基础设施,并尽可能减少开发人员内耗。平台工程关注的畛域包含创立和保护软件公布或CI流水线、自动化测试零碎、运行时环境和 Kubernetes 基础架构。  平台工程 vs DevOps面对日益简单的基础设施,平台工程正受到越来越多的关注。据 Gartner 预测,到2026年,80%的软件企业将建设平台团队,以帮忙将软件开发人员和IT运维以有机地形式联合起来。  许多人说随同着平台工程的衰亡 DevOps 已死,但它们之间并非此消彼长的关系:两种形式能够齐头并进一起帮忙企业胜利。“应该把它看成一种成熟或成长,而不是其中一个要来到了” Nashawaty说。  平台工程是 DevOps 的进阶,与 DevOps 领有雷同的指标,并帮忙 DevOps 更加高效。与 DevOps 相似,它提倡一种合作形式,重点是平台的创立。通过同时应用这两种办法,DevOps 团队能够在平台工程师创立的“舒服圈”中更快地编写代码。  ...

March 27, 2023 · 1 min · jiezi

关于devops:3-天交付新需求极狐GitLab-APP-极限编程-XP实践

近日,中移物联网有限公司、北京青云科技股份有限公司联结举办的 “2023 云原生重庆站技术分享会” 如期召开。会上,极狐(GitLab) 高级解决方案架构师刘剑桥带来《云原生极限编程 101》主题分享。本文整顿自演讲内容,你能够浏览到: 极限编程的 12 个外围实际;极狐GitLab APP 如何落地极限编程,实现 3 天交付新需要。Enjoy~ 极限编程(XP)是一个中小规模团队在面对含糊或者疾速变动需要时,开发软件应用的轻量级方法论。 XP 由 KentBeck 在 1996 年提出,是麻利软件开发中富有成效的几种方法学之一,它可能让客户满意度更高,更好地保护团队关系,更灵便且适配性更高。 极限编程的 12 个外围实际XP 由一系列简略却相互依赖的实际组成。接下来,咱们以软件开发的流程为主线,一一探讨实用而具体的 12 个外围实际。 实际一:用户故事用户故事次要解决需要廓清的问题。客户在提出需要之后,作为产品经理,须要对客户需要进行形容,造成相应的用户故事。 用户故事须要用户价值视角登程,是最小价值交付单位,例如手机号登录性能,对用户而言是有价值的;而如果形容为 “接口”,则是开发侧的工作。 实际二:打算游戏打算游戏是研发团队与利益相关者举办的打算会议,包含两个层级:公布打算和迭代打算。客户以及团队中的所有开发人员都要参加到游戏中,实现合力。 公布打算:团队和利益相关者/客户,基于用户故事独特决定在生产中交付的需要和性能以及工夫。迭代打算: 团队将从列表中筛选最有价值的需要,并将其合成为工作,而后进行预计和承诺,在迭代完结时交付。 实际三:频繁公布频繁公布(小公布,指需要很小)是指做完一个需要立即公布,能够以最快的速度失去真正的市场价值,如果发现有问题也能够更快速度纠正;跟瀑布模式有着本质区别。 实际频繁公布,须要在开发的过程中,始终保持与客户的双向沟通,及时处理用户的反馈,长期去影响并且使得客户获取真正的商业价值,造成一个正向循环,实现成就客户。 实际四:简略设计简略设计即不要超前设计,以可能满足需要的最简略的设计来实现工作;不要有反复的性能。 咱们平时会碰到一些比较复杂的场景,在这些场景下,在极限编程中也有 Spike(探针,一个用来摸索/寻找潜在解决问题的办法) 形式;后续有改变怎么办呢?还有重构与 TDD 来解决。 实际五:重构重构是依据须要来重构,而不是依据猜想来重构,更不要在重构时变更内部行为。 同时,咱们在实现产品的时候,有最小可行性产品(MVP)的概念,如果现阶段咱们还不晓得产品是否可行,那么,重构是一个实现最小可行性产品的具体技术办法。 实际六:测试驱动测试驱动开发(TDD)指先写测试用例再写开发,确保后续的开发都能够以最快的速度造成反馈,并且失去极高的覆盖率(后端 90% 以上,前端 70% 以上);并且是开发来写单元测试用例。 包含 4 步:写测试用例 → 确保测试用例失败 → 写代码确保测试用例胜利 → 有必要时重构。 实际七:结对编程结对编程由指所有的源代码都是两个开发人员在同一台电脑上编程的,能够造成实时的 Code Review。两个开发人员其中一人是编程的角色、另一人是策略角色。并且定时进行角色调换。 实际八:继续集成继续集成是指每次提交之后在服务器构建,并且在提交到骨干之后,再在骨干进行集成构建。 骨干合并应用极狐GitLab 预合并分支性能,这样能够提前做一些预合并,避免对骨干造成问题。继续集成的长处不言而喻:能够疾速发现问题,防止合并天堂,并且实现疾速公布。 实际九:现场客户现场客户即客户是团队的一员,参加团队开发,疾速反馈需要,时刻跟进停顿。 ...

March 24, 2023 · 1 min · jiezi

关于devops:Securtiy-Code-Reviewer-需要做些什么6个安全实例一探究竟

极狐GitLab 的 Securtiy Code Reviewer 是如何工作的? 近日,在极狐 TechTalk 直播上,极狐(GitLab) 资深后端工程师曹宝栋联合他的工作教训答复了这个问题,并通过极狐GitLab 历史上的一些 Bug 和破绽修复教训,诠释了 Security Code Review 的作用和意义。 以下内容整顿自本次分享,你也能够点击这里观看视频回放。enjoy~ 大家好!首先分享一下我在极狐GitLab 的一些工作成绩数据: 在极狐GitLab repo 下,奉献 MR  90+ 个;参加 Code Review MR 200 + 个。 下图展现的是极狐GitLab 成立至今,为 GitLab Inc. 所奉献的 MR 的数量:极狐GitLab 团队所奉献的 MR 数量目前居寰球第二,仅次于 GitLab Inc. 团队;其中我集体奉献数量是 72 个,波及 5 个不同 repo,外围 repo 是 GitLab。 明天分享的内容也是从这些理论开发工作登程,向大家介绍作为极狐GitLab 的 Securtiy Code Reviewer,我是如何工作的,并联合极狐GitLab 历史上的一些 Bug 和破绽修复,来看一下 Securtiy Code Review 关注重点是哪些。 为什么要做 Security Code Review?毋庸置疑,平安是很重要的话题,与研发相干的任何一个环节都有可能裸露平安危险。产品性能越丰盛,绝对应的平安危险面越大。 ...

March 23, 2023 · 2 min · jiezi

关于devops:研发效能负责人DevOps负责人

想要做好业务,老板们除了要梳理好公司级别的业务指标,公司的组织架构,还要搭个有产出的班子,也就是找负责人、建团队,让组织架构空虚起来。搭班子最重要的就是把负责人找到,就是团队1号位的人。本文次要讲团队负责人的次要作用,怎么能力找到,不同背景的优劣势,以及各方面的要求。 研发效力团队1号位「火车跑得快,全靠车头带」。团队1号位的能力,基本上决定了这个团队的下限。所以咱们在邀请1号位的时候要分外严格筛选。他除了要负责与其余部门协调、资源和估算治理、绩效考核等治理职责,作为领域专家还要胜任以下业余能力: 有大局观,有能力:能站在公司和团队的角度,依据公司策略和业务诉求,制订业务倒退的长期布局和短期指标。分清轻重缓急,解决做什么的问题。有打法:有能力布局出能达到目的地的可行的门路。解决怎么做的问题能打仗打胜仗:业务素质过硬,能打仗且打胜仗,即依照布局指标达到目的地的能力。我本人能做。带团队带队员:率领团队、激发团队推动业务倒退,造就团队成员。我也能够带团队做。如同没有比照就体现不出业务能力的差距,当然也看不到挫伤,那就举几个1号位已经提的问题: 为啥要有制品库?去掉制品库,都放到 svn 对立存多好。nexus干嘛的?让研发本人去下载 jar包,咱们就不必保护 nexus了,也就又少一事我的项目版本为啥是三位数?构建的包为啥四位版本号?是否对立用工夫戳?一站式研发治理平台为啥要管源代码?项目管理和源码要拆分到两个零碎不要搞 jar包的稳固版本,线上都发快照你给我一些输出,我打算下团队这个季度的OKR为啥公司里既有 svn 还有 gitlab?为啥xx公司都用 svn 就没事?公司半年总结,你总结下团队半年都做了啥,我散会时用 短少畛域把控能力,团队1号位容易变成「高低两级」的传话筒。 案例分享:已经据说过有位这样的研发效力团队负责人,之前从未做过研发效力工作,上级领导每次要求什么就都记下来,接着和团队上面每个人去聊。每个人聊过之后,开会讨论,而后会上让大家发言,发言时开始质疑每个人的认识。拿到后果和下级去汇报。 为啥是每个人?因为本人不懂,对团队上面的人又都不释怀,每个人都问一遍,答案能够相互印证下。为啥是散会质疑?通知你们我懂的,别忽悠我。为啥质疑团队成员后常常被怼?因为团队成员通知他的答案是有上下文的,有侧重点思考的。他质疑的时候往往摈弃了这些。开完会,拿着团队的计划和上级领导去交差,问到细节又不懂,散会回来怼团队。为啥不带着团队上面的人去散会?带着你们散会显得我多没本事。另外那是咱们领导级别的会咋可能让你们去。通过几轮这样的沟通之后,上面人的脑袋都开裂了。通常来说,作为业务1号位,要有随时能够做-2 层人员工作的能力。如果研发效力团队1号位对这个畛域没有足够的认知,团队规模越大,1号位对业务的倒退、对团队的倒退带来的妨碍甚至是挫伤也就越大。所以说业务能力是最重要的。业务1号位必须是这个畛域的专家。 团队1号位的背景领域专家非常少,找到真能独当一面的领域专家比拟难,尤其是有过一线理论「操盘」教训的1号位。这个时候咱们就要思考招什么样的人来率领这个团队了,甚至来搭建这个团队。尽管都是领域专家,然而领域专家的背景也可能不同。不同背景的人可能有不同的偏重 做下层业务的可能对基础设施建设不感兴趣,毕竟这块业务投入高工夫长成果慢。我看到很多之前做业务的人来做基础设施建设这块,没多久就又做业务去了。传统运维背景的人对底层基础设施建设会比拟重视,然而对业务体感低。这种状况我也见到过,对效力这块没想法,也不感兴趣;纯QA背景的人,可能更关注品质,但对反对产研工作自身的平台建设和实际可能关注少做后盾开发的人会好些,然而有可能对效力不感兴趣转去做公司主营业务,另外就是把研发效力当作只是开发一个工具来对待,会- 做出一堆货色,然而工具不好用,用户不想用,对公司帮忙无限,平台还不想改。我亲生的,怎么有可能错。长期做治理的人可能远离一线,实操不行。总之,咱们要好好掂量,咱们当初最须要补充的是哪方面的能力,而候选人的强项是哪些。如果员工和公司能同时成长,相互成就那就再好不过,如果不能,那么相互临时领有也挺好。员工对公司再好,公司也会开人;公司对员工再好,员工也要跳槽。单相思,始终是一种病态,最好还是相互奔赴,即使来到也互不赊欠。 团队1号位更要重视软素质不同阶段的公司1号位的要求兴许不同,但该具备的软素质始终都是要有的,比方耿直、诚恳、怠惰、上进、根本职场共识、自驱、靠谱 已经遇到这样一个案例,咱们有一个需要,团队评估了下大略2周左右能实现,交给一个小伙伴来做。后果这个小伙伴前前后后做了3个月没有实现。团队初创期间,业务还不确定,危险很高,对人的要求也是最高的,但最重要的是包含人品在内的基本素质。后期招进来的每一个人都是公司春天种上来的心愿的种子。每个人都是独当一面的,如果基本素质不过关,给公司带来的危险和危害也是最大。大家都尽量没有短板,能独当一面又能相互补位。 自驱也很重要。团队1号位刚进来,一片空白,百废待兴,很多时候都要本人去布局要做什么,做到什么水平,怎么做,谁来做,什么时候要有什么产出。如果团队1号位没点自驱力,那这个团队难以很快建设起来,业务也很难发展。 软素质对于每个团队成员都很重要,尤其是团队1号位就更重要了。 哪里找到这样的1 号位打入这个圈子,找到这个圈子最好的人聊一下。没错,咱们就有一个这样的「研发效力DevOps」的圈子,关注文末,猛戳咱们的公众号。 本文总结团队1号位要找到你能找到最好的那个人,基本素质要硬,人品素质硬,业务素质更要硬。既要也要又要到典型,没方法,团队1号位真的很重要。没有人品,待得越久危害越大;没有业务素质,一开始都待不上来或者只能「圆滑地」混下去,缓缓地容易把团队和业务带着向下走,甚至带没了,这样的案例太多了。 举荐浏览什么是研发效力?研发效力定义及外围价值研发效力的「道法术器」找到能做好研发效力的人互联网公司研发效力/工程效率团队建设和布局研发效力生态残缺图谱&DevOps工具选型必看

March 16, 2023 · 1 min · jiezi

关于devops:一图读懂CodeArts-Pipeline全新升级5大特性使能企业研发治理

2023年2月27日,华为云正式公布流水线服务CodeArts Pipeline,旨在晋升编排体验,凋谢插件平台,并提供标准化的DevOps企业治理模型,将华为公司内的优良研发实际赋能给搭档和客户,当初就跟着小编一起通过一张图来回顾CodeArts Pipeline五大要害个性吧!

March 15, 2023 · 1 min · jiezi

关于devops:企业如何构建内部开发者平台

平台工程是一种新兴的行业趋势,帮忙企业实现软件交付的现代化,减速企业数字化转型。企业通过平台工程,旨在进步开发人员的生产力以及开发体验,同时也为利用程序开发提供一个稳固牢靠的根底。平台工程团队通过构建外部开发者平台(Internal Developer Platform, IDP)将所有的技术和工具绑定在一起,设计和构建工具链和工作流程,涵盖应用程序整个生命周期的操作须要,让软件工程团队具备自助服务能力。  在明天的文章中,咱们将一起探讨 IDP 的基本概念与劣势,以及构建 IDP 的时候企业该当思考与留神的关键点。  什么是 IDP?外部开发平台,即 IDP,是建设在工程团队现有技术工具之上的一个自助服务层。IDP 是一个由经营团队开发的平台,使开发人员可能轻松地配置、部署和启动他们的利用基础设施,而不须要依赖经营团队。经营团队能够为组织的基础设施设置基线配置、模板、角色和权限,这样开发人员就能够自助服务于他们的工作需要。IDP 有助于进一步自动化经营工作流程,并通过简化应用程序配置和基础设施治理来补救和晋升工作效率。同时,IDP 还让开发人员有更多的自主权,使开发人员从编写代码到软件交付,都可能解决自若。  IDP 的益处与劣势面对企业日益增长的齐全自动化的疾速开发和公布周期的需要,IDP 为开发者提供为开发者提供创立、测试、部署和管理软件应用程序所需的工具和资源,可能帮忙简化我的项目,同时进步各团队成员的满意度。这里咱们列举出 IDP 以下几点劣势:  进步开发效率。IDP 可能帮忙进步企业开发团队的工作效率,为开发者们提供一个拜访所有他们须要的工具和信息的集中平台。同时,IDP 还能够使繁琐的过程自动化,例如启动新环境和浏览简单的部署。晋升软件品质。IDP 通过在整个开发生命周期中执行最佳实际、规范和政策来帮忙进步软件产品的品质。此外,IDP 还能够提供反馈和测试工具,帮忙开发者在生产前辨认和修复谬误。升高经营老本。IDP 通过优化资源利用,最大限度地缩小停机工夫和打消人工工作来升高企业的经营老本。IDP 还能够通过抽象化底层基础设施的复杂性,帮忙企业更容易和无效地扩大应用程序。增强团队单干。IDP 通过促成沟通、协调和常识共享来帮忙企业减少开发团队之间的单干。同时,IDP 可能通过与企业业务指标相干的零碎和平台集成,实现跨职能的单干。更好的开发者体验。IDP 加强了部署频率,进步生产力和可视性。同时还给予开发者们更多的自主权,最大限度地缩小了负载和筹备工夫,无效进步开发者积极性和满意度,激励他们尝试更多新的外部配置,使开发者们可能提供更快的应用程序公布周期,从而缩短产品上市工夫。更好的灵活性。IDP 可能帮忙企业在开发过程中实现更好的灵活性,依据企业具体需要和偏好定制你的平台设置和流程。IDP 还能够反对多种语言、框架和技术,以满足您的我的项目要求。用户体验更佳。IDP 帮忙企业提供更好的客户服务,提供更高质量的产品,对客户的反馈或问题作出更快的反馈,并疾速牢靠地部署更新或修复。 企业内各团队如何受害于 IDP?IDP 作为一个集中化自助服务平台,不仅使开发人员受害,也能够让参加软件开发过程的其余团队也从中受害。例如:  经营团队。IDP 能够帮忙经营团队最无效地利用技术和工具,均衡工作量且加重压力,并将所有的重复性工作自动化,从而进步团队的生产力。IDP 还能够帮忙经营团队整合和协调现有的基础设施和 CI/CD 流水线,监控和排除问题,执行平安和合规政策,以及优化资源利用。开发团队。IDP 能够帮忙开发团队不依赖经营,应用事后配置的平台配置和流程,自行治理部署和环境,从而放慢应用程序的公布周期。IDP 还能够帮忙开发团队取得反馈和测试工具,在问题达到生产环境之前辨认并将其修复,试验新的外部配置。应用多种语言、框架和技术进行翻新;并提供满足客户冀望的高质量产品。业务团队。IDP 可能帮忙业务团队实现更短的产品上市工夫,使应用程序的公布周期更快。IDP 还能够帮忙业务团队与客户的需要保持一致,让业务团队对反馈或问题作出更快的反馈。此外,IDP 可能帮忙企业团队通过优化资源利用,最大限度地缩小停机工夫和打消人工工作来升高经营老本。 企业如何构建 IDP?构建外部平台前须要思考的因素当企业决定构建 IDP 前,咱们倡议企业该当先思考以下几点因素:  业务需要和指标:在构建外部平台之前,理解平台须要反对的特定业务需要和指标十分重要。这包含辨认将在平台上运行的应用程序和服务的类型,以及预期的流量和应用模式。现有基础设施和工具:思考现有的基础设施和工具也很重要。这包含评估现有解决方案并确定它们是否能够利用或与新平台集成。可用资源:构建外部平台须要大量资源,包含估算、团队规模和专业知识。重要的是要思考可用资源并确保这些资源和信息足以反对平台的开发和保护。 构建外部平台的步骤构建 IDP 是一个简单且高老本的过程,因而企业在构建时须要认真地布局、钻研、设计和施行。以下是倡议的 IDP 构建步骤:  定义需要和指标:构建外部平台的第一步是明确定义平台的需要和指标。这包含确定将在平台上运行的应用程序和服务的类型,以及预期的流量和应用模式。评估现有解决方案:定义需要和指标后,评估现有解决方案以确定它们是否能够利用或与新平台集成十分重要,包含评估开源和商业解决方案。抉择适合的技术栈和架构:在评估现有解决方案后,为平台抉择适合的技术栈很重要。这包含抉择要应用的适当语言、框架和工具。同时,企业须要依据后期调研后果来抉择和设计 IDP 架构,例如思考如何模块化、整合和协调组件;如何形象出复杂性;如何确保可扩展性、可靠性、安全性和合规性;如何提供反馈和测试工具;如何实现定制和试验,等等。施行和测试平台:确定好了技术堆栈和架构之后,就能够施行和测试平台。这包含开发平台、将其与现有系统集成以及对其进行测试以确保其满足第一步中定义的要求和指标。例如评估影响:评估 IDP 对开发过程和后果的影响,掂量要害性能指标(KPI)。例如部署频率变更的前置工夫(Lead time for changes),均匀复原工夫(MTTR),变更失败率(Change Failure rate),客户满意度等。此外,倡议企业收集用户和软件开发相干团队的反馈,以确定须要改良或进步的中央。部署和保护平台:平台施行和测试后,部署和保护就很重要了。这包含配置和部署平台、监控平台以确保其安稳运行,以及执行定期维护和降级以使其放弃最新状态。  参考链接: https://www.xenonstack.com/insights/internal-developer-platformhttps://www.qovery.com/blog/guide-to-platform-engineering-goa...https://www.infoworld.com/article/3610335/what-is-an-internal...

March 14, 2023 · 1 min · jiezi

关于devops:3-问-6-步极狐GitLab-帮助企业构建高效安全合规的-DevSecOps-文化

本文起源:about.gitlab.com作者:Vanessa Wegner译者:极狐(GitLab) 市场部内容团队 平安为何重要?此前,咱们分享了: 1. 2023年DevOps发展趋势重磅!GitLab 提出五大预测,洞见 2023 年 DevSecOps 发展趋势 2. 古代软件为何须要新的应用程序平安办法 GitLab 专家分享:对于 DevSecOps ,你须要晓得这几点 明天咱们来看,如何构建高效、平安、合规的 DevSecOps 文化,enjoy~ 你须要为平安负责吗?如小标题所问,兴许平安不在你的岗位和工作形容中,然而答案是必定的:你须要为平安负责。 任何一个员工都应该为其工作的平安负责。可怜的是,很多组织并没有明确阐明这一点,也没有将平安作为政策来执行。随着安全漏洞在平安工程师的桌面上堆积成山,研发人员迫切想晓得:要经验多少次修复,代码才是平安的? DevSecOps 颠覆了传统的安全性,但须要弱小的平安文化,能力取得继续胜利。 什么是平安文化?平安文化意味着所有人——从董事会成员到实习生,都必须关注平安并口头起来保障平安。每项决策和每项工作都应该思考安全性。 这仿佛违反直觉,而且也不是 DevSecOps 承诺的效率。然而,将平安嵌入到每个员工的日常行为中,平安团队的工作量就会大大减少,最终的产品也会更平安。这就是很多公司议论的“平安左移”:在软件开发生命周期中,将平安前置,以改良布局、测试更多代码并在非平安团队成员中建设问责制。 如何让平安文化成为你的默认状态?你必须将平安纳入新员工入职培训,否则很难创立一个司空见惯的平安文化。因为员工须要以不同的形式思考和行事,并最终将这些扭转变成习惯,让平安成为他们日常工作的天然组成部分。 Step 1: 文化改革始于高层如果你的组织将平安留给了 “某个团队”,构建平安文化首先须要让董事会成员和管理层都参加到这场改革中。通过将平安作为全公司的动作来定下基调,让每个人都晓得平安是重中之重,而无关乎工作职能或组织模式。 Step 2: 意识、教育和相互理解要为员工提供培训,让员工理解如何将平安交融到他们所做的每一件工作中。 透明度是构建信赖的要害,因而员工须要晓得平安为什么重要以及为了实现平安指标,他们能够做哪些方面的奉献。另一方面,须要让培训人员理解业务和 DevOps 实际对平安的需要。这有利于培训人员帮忙你的团队独特制订让平安和研发紧密结合的策略。 Step 3: 在开发中寻找 “平安冠军”一些员工会很激情地拥抱平安,那么为这些 “平安冠军” 提供额定资源和教育机会,减少他们的常识,并使他们成为四周人的求教对象和资源,这是十分有帮忙的。 Step 4:激励跨职能团队合作应该让团队成员在跨职能团队合作时感到舒服,诸如问问题、分享信息(非敏感信息)。 DevSecOps 通过突破 “仓筒” 来创立更高效的流程,这么做的确有助于改善沟通,并在团队之间建设友情。如果将平安归属于多团队的致力,员工将感触到激励而退出平安工作流中。 Step5:给开发者提供他们须要的工具如果安全措施可能无缝融入开发人员的工作流程,将更容易被采纳。 平安即代码施展着重要作用:当策略、测试和扫描集成到流水线和代码自身时,开发人员能够进行更平安的工作。过多的工具切换,会对消平安左移的益处,因而,最好使你的技术堆栈尽可能简略以来放弃效率。 Step6:适当的自动化自动化对于大规模推动安全性来说至关重要,而且对于非平安人员而言,也更能容易被承受。 例如在开发人员的工作流中,能够针对每次代码变更进行动态应用程序平安测试(SAST)。这些扫描后果就会主动填充到平安仪表盘中,领导下一步工作。 平安不是可选项,而是必选项平安文化的构建,值得付出致力。将平安作为你团队的首要任务,增强技术进攻,将帮忙你抵挡一直变动的威逼,继续进行翻新。

March 9, 2023 · 1 min · jiezi

关于devops:GitLab-凭借什么连续-3-年上榜-Gartner-应用程序安全测试魔力象限听听-GitLab-自己的分析

本文起源:about.gitlab.com作者:Sandra Gittlen译者:极狐(GitLab) 市场部内容团队应用程序平安测试(AST)对于应用程序研发来说,是一个正在疾速倒退并且非常重要的畛域。DevOps 方法论提到:须要将测试集成到开发人员的工作流中。GitLab 置信在软件研发中,AST 越成熟,应用程序就会越平安,同时企业也可能更容易满足合规要求。置信 DevSecOps 平台化策略,也就是将平安嵌入到 DevOps 生命周期即从打算到上线全过程,可能比传统应用程序平安测试,提供更高的效率和价值。 2022 年 Gartner 应用程序平安测试魔力象限中,GitLab 位列挑战者象限。依据 Gartner 的说法:“撑持企业落地实际 DevSecOps 以及云原生转型,是 AST 市场倒退的次要驱动力。” 这是 GitLab 间断三年在 Gartner 应用程序平安测试魔力象限中取得认可。 “咱们很快乐看到,将平安嵌入 DevOps 工作流程这种独特办法,具备继续的发展势头。”GitLab 产品治理总监 Hillary Benson 示意,“咱们置信,挑战者魔力象限的认可,代表市场对 DevSecOps 办法和价值的深刻了解,这种办法赋能开发人员发现和修复破绽,并通过 DevOps 平台晋升便利性。” GitLab 一体化 DevOps 平台提供了 DevOps 所需的自动化,以及平安专家所需的策略和破绽治理性能。极狐GitLab 作为 GitLab 中国发行版,极狐GitLab / GitLab 提供了一系列已集成的、可审查、可治理的扫描器,满足古代应用程序研发以及云原生环境下的平安合规需要。 独特的 AST 办法GitLab 在应用程序平安畛域继续翻新。让咱们来看看,GitLab 和传统 AST 厂商有何不同。正是这些差别带来了应用一体化平台来实现 DevOps 和平安的泛滥益处。例如: GitLab 将更全面的扫描集成到 CI 流水线中,以便构建出更具备交互性的测试环境。 这是一种独特的办法,有别于将产品重点放在基于工具的交互式 AST。在 GitLab 上,开发人员可能更加全面地理解安全漏洞的产生,这也让开发人员可能更高效地去解决这些平安问题。 同样,尽管 Gartner 分析师将重点放在相似拼写查看的轻量级 SAST 性能上,但咱们发现这些性能对于 GitLab 用户来说,并不是那么重要。当然,这也是因为 GitLab 将性能内置了。打个比方:咱们习惯于常常保留文件,这样编辑的文件就不会失落。开发人员开发软件时也在做同样的事件:变更被频繁 “提交” 到代码仓库。 ...

March 8, 2023 · 1 min · jiezi

关于devops:DevOps-与平台工程企业该如何选择

在之前的文章中,咱们相熟了平台工程的基本概念,包含平台工程的特点、次要劣势以及实际准则。通过理解咱们不难发现,平台工程与 DevOps 还是有许多相似之处的。例如这两者都是一种文化和办法,旨在通过自动化、自治和合作来简化开发过程。同时,DevOps 与 平台工程都致力于进步软件交付的品质和速度,以及加强团队之间的沟通和翻新。除此之外,这两者都让开发人员可能自助地应用工具和资源,而不须要依赖于其余团队或部门。  那么在明天的文章中,咱们将会一起探讨平台工程与 DevOps 的区别是什么,以及企业在抉择施行 DevOps 或平台工程须要思考哪些因素。  平台工程与 DevOpsDevOps 是一种概念思维形式,用于定义开发和经营合作的形式。而平台工程是创立具备定义工具和工作流集的集中式平台。企业各畛域之间的合作需要须要新的工具来突破孤岛。DevOps 团队须要负责寻找和保护工具和工作流,而平台工程通过为 DevOps 团队提供工具和工作流的地方平台来缩小认知累赘,平台团队在与 DevOps 团队成员进行深刻沟通后抉择最合适的工具。这样,开发人员就能够间接应用取得的工具,而不须要从新构建和保护一整套工具和工作流程。  DevOps 和平台工程的次要区别在于: DevOps关注的是软件开发与运维之间的合作与沟通,而平台工程关注的是为软件开发提供一个牢靠、灵便、易用的平台。DevOps波及到多个角色(如开发人员、测试人员、运维人员等),而平台工程波及到一个专门的团队(即平台团队),负责构建、保护、优化平台。DevOps应用各种现有或定制的工具来实现继续集成、继续交付、继续部署等指标,而平台工程应用对立的外部开发平台(IDP)来提供这些性能。DevOps须要一直地调整和改良流程和文化,以适应不同的我的项目和需要,而平台工程须要一直地更新和扩大平台性能,以满足不同的用户和场景。 同时,平台工程团队与 DevOps 团队的职责与受众也有所不同: DevOps 团队专一于交付应用程序的技术性能(只管一些 DevOps 团队抉择比这更宽松的定义)。平台工程团队专门专一于构建和保护平台。这包含确定开发团队以及组织中将从应用该平台中受害的任何其他人的需要。DevOps 团队有时负责间接向内部受众(如软件客户)公布性能。平台工程师向外部客户(如 DevOps 团队)解释并宣传平台。DevOps 团队将钻研与其交付重点相干的特定技术和工程问题。平台工程团队将通过找出他们的客户(开发人员)须要什么来定义他们的平台。 总之,DevOps和平台工程都是为了晋升软件交付效率而采取的措施,但它们侧重于不同的方面。DevOps 是一种软件开发和IT运维的方法论,它通过集成和自动化的工具和实际,来进步和缩短零碎开发生命周期,DevOps 更强调过程优化。平台工程是设计和实现工具链的过程,这些工具链能够改善软件交付体验。而平台工程更强调技术创新,平台工程师建设自动化的基础设施和自助管制,让开发人员可能更高效地工作。平台工程能够说是 DevOps 的演进。  平台工程会取代 DevOps 吗?那么,平台工程会取代 DevOps 吗?答案是否定的。  平台工程与 DevOps 并不是竞争或抵触的概念,而是一种补充模式,直白地说平台工程是实现 DevOps 指标的伎俩之一。平台工程和 DevOps 是两个维度的概念,前者更偏差一套机制和架构,后者多指一套方法论。平台工程并不会取代 DevOps,而是随着和上层基础设施、下层业务的生产关系边界划清,本身生产工具套件的成熟,去成就更好的 DevOps。平台工程要求基于 Kubernetes 的底层平台具备安全性、灵活性、稳定性、先进性。  DevOps 作为一种软件开发和交付的办法,旨在实现开发和经营之间的合作和自动化,进步软件品质和效率。DevOps 波及各种技术、工具和流程,如继续集成、继续交付、微服务、容器化、监控等。而平台工程是一种机制和架构,用于构建和经营支持软件交付和生命周期治理的外部开发者自助服务平台。平台工程旨在为开发人员提供一个对立的、标准化的、可扩大的、可重用的基础设施层,使他们可能专一于业务逻辑,而不用放心底层的复杂性。  平台工程与 DevOps: 企业如何抉择?在理解 DevOps 和平台工程的类似与不同之处后,企业该当如何为本人的我的项目作出最优抉择呢?在抉择 DevOps 还是平台工程时,能够思考这几个因素:比方企业组织的规模和复杂性,企业软件开发过程的成熟度和指标,以及公司外部工程师的可用性及其所把握的技能。  相比之下,DevOps 更适宜于规模较小或较简略的组织,这些规模的企业往往心愿利用自动化、自主性和合作来简化开发流程。DevOps团队专一于交付应用程序的技术性能,并进步其品质和速度。DevOps 须要文化上的转变,以及开发人员和经营人员之间高度的沟通和协调。  而平台工程则更适宜大型或简单企业组织,这些企业通常心愿通过自动化基础设施操作提供自助服务能力,从而改善软件交付体验。平台工程师设计并施行工具链,使开发人员可能在不依赖其余团队或部门的状况下更无效地工作。平台工程是 DevOps 的演变,它能使开发人员实现自我服务,并缩小经营开销。平台工程须要高水平的技术特长和对平台的架构和性能有清晰的意识。  当然,企业在进行抉择时,须要依据其需要和能力在思考施行 DevOps 或平台工程,亦或者采纳一种混合的办法,将两者联合起来在企业内施行,以更好地服务企业的软件开发我的项目。 ...

March 7, 2023 · 1 min · jiezi

关于devops:我在京东做研发-揭秘支撑京东万人规模技术人员协作的行云DevOps平台

分享人:孙长虹 京东云DevOps解决方案架构师 复旦大学计算机系毕业,并领有人民大学心理学硕士学位。曾任职于Alcatel-Lucent,IBM和惠普,具备丰盛的大型简单产品研发及项目管理教训,善于组织级麻利和DevOps转型,并领有EXIN Agile Coach, 业务麻利,DevOps Master,以及SPC认证,也是EXIN受权麻利和DevOps讲师。他负责京东云DevOps解决方案,也为批发、金融、交通等多个行业的大型企业客户提供过麻利和DevOps咨询服务。 大家好,欢送来到我在京东做研发系列直播,我是来自京东科技的解决方案架构师孙长虹,明天我给大家带来的直播主题是:探索京东DevOps,云原生IT研发模式的改革。 Question:如何了解DevOps与云原生之间的关系?孙长虹:依据Pivotal的定义,云原生包含DevOps、继续交付、微服务以及容器;其中,继续交付也是狭义的DevOps一部分,因而从概念上来讲,DevOps既是云原生的重要组成部分;同时也是云原生能力的一个集大成者。 云原生是业务疾速变动背景下的必然技术趋势,云原生关乎速度和敏捷性,它的价值在于减速企业把新想法推向市场进行验证和实现增长;而DevOps可能帮忙企业疾速、频繁和牢靠地交付软件,从而实现云原生价值。 云原生带来了IT改革,次要包含软件架构的改革和研发模式的变动,软件架构的变动是大型单体利用向微服务的转变,研发模式的变动是大批量阶段式或瀑布式的开发向小批量增量开发的转变。而麻利和DevOps的理念、办法和实际是以后研发模式改革的次要伎俩。 接下来我将率领大家从四个方面一起探索京东的DevOps:介绍京东对DevOps的了解和所做的摸索,而后重点介绍积淀了京东DevOps教训的行云研发协同平台,它的一些要害个性和典型利用场景。随后介绍一下京东云所能提供的DevOps转型服务。 Question:软件开发复杂度晋升带来了哪些问题?孙长虹:如果让咱们用一个词来形容以后的时代特征,那么VUCA肯定会排在前列。VUCA是易变性、不确定性、复杂性和模糊性这四个词的首字母缩写。在VUCA时代,命令与管制的传统形式不再实用,组织必须可能疾速响应变动和不确定性,灵便应答复杂性和模糊性。 与此同时,软件在这个时代的重要性与日剧增。 早在2011年,原网景公司的创始人安德森提出“软件吞噬世界”这一大胆阐述,现在这一构想逐步成为事实;譬如随同着新批发的崛起,有人提出“程序员吞噬批发”的说法;随同着汽车技术的飞速发展,又有人提出“软件吞噬汽车”的阐述。无论如何,简直当初所有业务都离不开软件,软件曾经成为企业的外围竞争力。 然而,软件的复杂度一劳永逸,使得交付过程困难重重,这是一个典型的软件交付过程的价值流: 在需要分析阶段,遇到了像业务需要含糊,需要不确定性,剖析周期长等艰难。 在布局排期阶段,经常有大量的需要积压;以及跨团队的开发排期难等问题。 在设计和编码阶段,会遇到需要变更多,跨零碎联调的艰难。 而在功能测试阶段,很多团队仍旧依赖手工测试,品质问题多,从代码到测试的整个过程的周期长,代码品质低,返工多等。 在SIT/UAT阶段,会遇到集成工夫晚,集成问题的排查难等艰难。 从布局到最终的上线,又会遇到利用之间耦合大,跨团队协调简单,集成周期长等艰难。 在部署公布阶段,传统手工投产过程十分软弱,容易呈现问题,问题追溯艰难也都很常见 端到端地看,就会发现:业务需要的前置工夫长,开发过程不通明,不可预测,需要变更艰难,需要价值不明确,大量低质量需要产生了大量节约等各种艰难。 软件开发是一个简单的过程,先驱者们得出软件开发须要采纳经验性过程的论断。经验性过程是绝对于“已定义过程”而言的,所谓已定义过程,就是在一个我的项目开始的时候,就制订具体的打算,辨认全副的工作项,而后在整个我的项目执行过程中,严格遵循打算,直至所有工作实现。经验性过程是在我的项目之初明确指标,把高优先级的工作项辨认进去;而后用增量的形式继续进行检查和调整,直至指标达成。 Question:麻利在不同期间的定义是怎么的?孙长虹:传统的定义过程,只能反对简略类型的工作,为撑持简单工作,必须采纳经验性过程,也就是麻利组织这样一种工作形式。正如Scrum指南中所指出的,Scrum是为了解决简单问题的。麻利的重要性早就失去了行业领先者们的器重。 IBM在其《CEO Study》中所论述的,CEO们的首要任务是晋升企业的业务敏捷性,以应答疾速变动且高度简单的环境。而麦肯锡公司在《麦肯锡月刊》中指出:3/4的受访者示意,组织敏捷性是头等大事,近40%的受访者目前正在进行组织敏捷性转型。 麻利并没有一个明确的概念。在传统软件开发办法无奈应答疾速、多变、和动静市场环境的背景下,作为一种代替办法被提出。以《麻利宣言》为标记,包含一组价值观和准则,多种软件开发框架和办法,以及一系列最佳实际。 麻利有这样一些具体特色: 1、以客户为核心关注价值,即由客户定义价值,并且由价值来驱动开发,另外就是最小可行产品进行测试和学习,以增量的形式来进行交付,先交付小批量性能,通过用户的反馈来失去学习; 2、跨职能自组织团队通力协作,即组建跨职能团队,可能负责端到端这样一种交付,另外3、端到端的疾速流动和及时的反馈,以及继续的改良工作办法。 如果咱们认真扫视这些特色,会发现这些特色岂但实用于软件开发,本质上麻利曾经成为一种新的工作形式,不仅仅利用在IT,而是广泛应用在整个组织。 Question:DevOps如何演进?孙长虹:DevOps,实际上是继承了精益和麻利办法,并将其渗透到整个交付过程。采纳大量卓越的技术实际,它是交付方法论和技术实际引进的这样一种交融,从而使得组织可能更加疾速、频繁和牢靠的去构建、测试和公布软件,以满足业务的这种疾速变动的要求,使得企业更加适应市场竞争的须要。 正如出名的钻研机构Forrester所指出的那样,当初各行各业都在做数字化转型,要想取得数字化的收益,就须要一些具体的动作,比方挪动利用 互联网 大数据等等,然而将数字化转型仅限于这些动作是远远不够的,该当专一于在他们上层更为要害和根本的需要,也就是为未知未来的继续的商业和技术改革做好筹备。数字化是要求企业具备应答变动的能力,麻利和DevOps恰好能够帮忙企业实现IT的转型,帮忙企业在业务上可能具备适应变动的能力,从而被认为是数字化转型的一个根本的能力。 Question:京东在DevOps方面的摸索历程如何?孙长虹:京东在DevOps的摸索次要从两方面发展:一方面是实际,比方麻利或DevOps的治理和工程实际,包含像Scrum、看版办法、业务麻利、继续集成、继续交付、DevOps等等。另外一方面是撑持这些实际落地的工具在整个团体层面的继续演进。 具体来看,京东在DevOps的摸索有三个畛域: 第一个畛域是晋升研发的管理水平。讲到研发的管理水平,其实咱们面对的问题不是没有办法,而是咱们所面临的办法太多,京东在摸索中基于典型的研发场景,组合一些办法和实际,并且失去了工具平台的这样撑持,从而达成在各个场景下的指标。 第二个摸索的畛域是加强研发的工程能力,咱们当初所应用的很多的研发的工程的实际办法,实际上曾经存在很长一段时间,京东在DevOps摸索中,基于DevOps平台的价值流,把各种工程技术的实际做了有机的整合,从而能产生更大的效用。 第三个摸索畛域是研发的效力度量,京东领有一个组织级的研发效力度量的一个体系,像度量根本准则、指标的抉择的准则等。基于京东价值流交付模型,也建设了一系列残缺的指标体系,而后在行云效力度量平台的撑持下,实现度量数据的一种场景化的利用,从而撑持效力的继续的改良。 京东的DevOps摸索能够稀释在这张DevOps全景图里。 在这张全景图的最上面,是一系列的最佳实际,包含需要和业务的实际、编码的实际、开发的实际、测试的实际,以及运维的实际等。所有这些实际都由一些具体的效力组件来撑持,例如项目管理、需要治理、代码库、流水线等,基于DevOps一体化的这种理念,咱们整合了这些组件,造成了一个面向一线产研用户的一体化平台,包含我的项目合作域、开发域、测试域、运维域等。基于这个平台的大规模利用,积淀了很多研发数据,基于这些数据又能够做研发的效力度量,基于效力度量实现的业务洞察,来继续改良咱们的实际组合,进一步的做提炼。 京东的DevOps教训能够提炼成黄金三角,黄金三角的核心是其指标,也就是疾速、晦涩、牢靠和可继续的交付价值。三角的三局部,别离是效力实际,它是京东多年多状态大规模研发效力的实践经验,这些教训积淀在效力平台上,这个效力平台是一站式的DevOps平台,笼罩了软件交付的全生命周期,也撑持了整个组织的大规模的研发流动的发展,第三局部是效力度量,效力平台产生的数据,对它进行开掘造成洞察,能够用来优化效力实际,随着效力实际的晋升,来进一步对效力度量提出更高的要求,也欠缺效力度量。与此同时效力度量的利用也推动了效力平台在整个团体的利用更加深刻。这三者是相辅相成的关系。 效力平台作为另外两个局部效力实际和效力度量的一种撑持,起到了整个京东研发效力底座这样一种作用。 Question:行云DevOps研发效力平台有哪些要害的个性?孙长虹:这里列出了行云DevOps平台的一些外围的性能。次要包含这么几个局部: 首先是治理合作域,它包含面向项目管理人员PMO的项目管理能力。 第二局部是需要治理,是面向业务人员的需要的端到端的治理。 第三局部是团队空间,是面向研发团队的治理研发工作,麻利的迭代撑持,都能够在这里失去了反对。 另外是测试治理,是面向测试人员,包含像一般的测试用例的治理、测试计划全线的跟踪提测等。另外就是工程合作域,包含京东自研的大规模代码库,自研的大规模流水线,以及部署和公布这样的能力。右上角是行云的效力度量。基于平台所积淀的研发流动数据,进行效力的剖析和洞察,从而反对效力的继续改良。 不同的DevOps平台,在性能上其实差别并不是很大,京东通过多年的大规模利用,也造成了本人的一些要害个性,这里列出了8个要害个性。 第一个要害个性:端到端对立价值流。Gartner在2021年曾提出精益的价值流将会被融入DevOps的阐述,同时也提出了价值流交付平台的概念。这个价值流交付平台就是国内的DevOps一体化平台。京东在这一块走的更进一步,岂但具备端到端的一体化的平台,实现了整个价值流在线上的协同,价值流的可视化以及可改良,具体来说,首先京东在整个团体层面对立了研发价值流;其次实现了从业务提出需要,到最终需要上线和收益验证,端到端流转的线上化,基于对立的研发价值流,造成了整个团体层面对立的研发效力的指标定义,此外在各个研发团队的层面又能够依据本人的理论状况,灵便定义本人研发一个状态,以及这些研发状态的流转的规定,简略来说,就是通过DevOps一体化的平台,可能落地京东的这种价值流交付的模型,为整个团体层面的研发协同和效力度量奠定了根底。 第二个要害个性:多视角和跨畛域的协同。第一个视角其实是业务的视角,整个需要的端到端的跟踪,第二个视角是产品视角,赋能产品经理,可能对本人的产品进行布局、进行价值摸索,进行继续的经营。第三个视角是研发的视角,治理研发流动,治理研发的工作工作 以及反对像麻利开发,第四个视角是面向传统的项目管理,以及PMO的视角,实现了像工时的治理,整个我的项目范畴里程碑危险的治理等等。 第三个要害个性:端到端的流程买通,以及整个研发流动的晦涩连接。需要从提出之后,进入了需要治理,在需要治理模块进行需要的一种受理,需要的沟通,并把业务需要拆分成一个个IT零碎的一种产品需要,再把产品需要调配到一个个研发团队,在研发团队会并行的进行开发和测试,开发人员应用代码库进行代码治理,提交代码,而后触发了代码的质量检查以及代码的评审,代码提交之后,触发了主动的流水线,实际主动的构建,包含主动的冗余验证,测试人员基于,开发人员的提测来进行测试的布局,而后执行测试、治理缺点。行云研发协同平台也集成了一系列的自动化测试的能力,能够被流水线调用,或者是在测试人员执行测试的时候曾经调用。在这里咱们实现了自动测试和测试治理的对立,对立自动测试和手工测试使劲,对立执行,而后造成对立的测试报告,通过验证的制品,会进入制品库,而后通过部署和公布利用,把它公布到指标的环境中去,包含线上环境。总结一下,从业务提出需要,到产品和业务沟通受理需要,需要调配到开发团队,而后再执行具体的开发和测试的工作,直至上线验收,以及收益的一个验证,实现了全流程的线上化,整个的过程全是买通,并且是十分晦涩的进行连接。 第四个要害个性:数据的关联全程可追溯。基于价值流,也就是需要,咱们把各种治理对象都进行了关联,比如说与代码进行关联,与测试进行关联,与缺点进行关联,与公布进行关联等,从而实现了全程的可追溯。 第五个要害个性:状态的更新。可能实现主动和精确及时的这样一种状态的更新,咱们在做效力度量的时候常常会遇到这样一个问题,平台上采集的数据有可能不精确,解决这个问题,诚然能够采纳一些管理手段,然而行云提供了一种技术手段。行云提供了需要评审的线上评审能力,咱们在线上进行需要评审,评审通过之后,这个需要的状态就主动流转到待上线,因为咱们的需要也是跟代码进行关联的,当开发人员创立分支进行编写代码的流动的时候,这个需要的状态就自动更新到那个开发中,当开发人员进行提测,测试人员开始测试之后,需要就主动的进入到测试中的状态,当测试人员实现这个提测标记提测通过,这个需要又会主动的将其状态变为待上线,整个端到端的绝大部分的这个过程的这种状态,都能够自动更新,从而保障了研发过程数据的精确,以及疾速的失去采集,从而撑持了咱们更好的去做效力度量。 第六个要害个性:能力的凋谢比拟容易扩大,行云研发效力平台,提供了欠缺的凋谢API 领有插件化及组件化的能力,易于集成和被集成,同时行云通过利用商店,建设了整个的工具链生态。 第七个要害个性:平安和高可用。从网络应用数据和运维多个层面确保安全,全链路的端到端的高可用,另外采纳K8S集群部署,确保无单点故障。 第八个个性:国产信创和自主可控,整个平台采纳了纯自研的架构,基于包含芯片、服务器、操作系统以及数据库和中间件全栈的国产信创生态,实现了自主可控。 ...

March 3, 2023 · 1 min · jiezi

关于devops:GitLab-专家分享|关于-DevSecOps-你需要知道这几点

本文起源:about.gitlab.com译者:极狐(GitLab) 市场部内容团队 灵魂拷问:你的平安测试,是否跟上古代软件开发模式的步调? GitLab 预测到,2023 年企业会将更多的工夫和资源投入到继续的平安左移上,是时候实现从 DevOps 到 DevSecOps 的演变了。 详情请戳:重磅!GitLab 提出五大预测,洞见 2023 年 DevSecOps 发展趋势 本文将持续探讨为何古代软件须要新的应用程序平安办法——DevSecOps。 在传统研发模式中,平安,往往在软件开发生命周期的前期才被染指。当代码不可避免地返回给开发人员修复时,就减少了老本和工夫。 DevSecOps 将平安集成到残缺软件开发生命周期中,是一种将研发、平安和经营/运维交融在一起的软件开发办法。 DevSecOps >> Dev+Sec+Ops与传统流程相比,DevOps 将研发和运维交融在一起,以此来进步软件开发和交付的效率、品质及安全性,而更加灵便的软件研发周期,将为企业及其客户带来更多竞争劣势。 DevOps 能够形容为在保障研发速度前提下,让多个角色良好协同,一起构思、构建和交付软件。DevOps 实际可能让研发 (Devs) 和运维 (Ops) 通过自动化、合作、疾速反馈以及继续改善四个方面来减速软件交付。 只管 DevSecOps 只是在 DevOps 两头嵌入 Sec 字样,但其产生的成果大于 Dev + Sec + Ops 的总和。 DevSecOps 是 DevOps 的演进,通过工具和办法来爱护和监控实时应用程序的部署,将应用程序平安实际融入软件开发的每个阶段,包含新的攻击面,诸如容器和编排器,必须要与应用程序自身一起监控和爱护起来。 DevSecOps 工具通过自动化平安流程,创立让研发和平安团队双双受害的流程,进而突破 “部门墙” 并改善合作。通过将平安嵌入到软件开发流程中,始终确保疾速研发和迭代过程的平安,在不就义品质的状况下提高效率。   什么是应用程序平安? 应用程序平安是应用软件、硬件和过程办法来爱护应用程序免受内部威逼。古代办法包含平安左移,或在软件研发晚期发现并修复安全漏洞,以及通过平安右移在生产环境中爱护应用程序的基础设施即代码的平安。 爱护软件开发生命周期自身是一项能力要求。这种将平安高效整合进研发和运维流程中的平安构建形式,让你从 DevOps 演进到 DevSecOps。而一个端到端 DevOps 平台能够很好地实现这个指标。 DevSecOps 根本要求,自动化+合作+策略保障+可见性被奉为 DevOps 圣经的书籍——《凤凰我的项目》中形容了自动化、一致性、度量和合作的重要性。DevSecOps 办法同样也是利用这些技术来打造软件,同时在整个过程中嵌入平安性能,而不是在一个独自的、孤立的过程中发展平安保障措施。 只管研发和平安团队都可能发现破绽,然而通常须要研发人员去修复这些破绽。让研发在编写代码的同时发现并修复破绽,是十分有意义的。不仅仅是平安扫描,而是在正确的工夫、正确的背景即上下文,将后果及时反馈给正确的人,以便疾速采取行动。 DevSecOps 的根本要求包含自动化、合作以及策略保障和可见性。 ...

March 2, 2023 · 1 min · jiezi

关于devops:DevOps-与-FinOps二者可以协同吗

DevOps 是一个强调开发人员和经营团队之间的合作和自动化以创立更高效的软件开发生命周期的过程。随着云业务老本逐年攀升,甚至超过传统基础设施老本,许多企业开始转向 FinOps 以无效降本增效。FinOps 与 DevOps 相似,旨在促成合作和效率,但重点是财务经营而非软件开发。在明天的文章中,咱们将谈谈 DevOps 与 FinOps 之间的区别与差别,同时探讨如何将二者联合应用来发明高效且老本更低的软件开发流程。  DevOps 与 FinOps:基本概念DevOps 是开发和经营的联合,这是一套专一于减速软件开发的准则、最佳实际和工具。旨在以比传统软件开发形式更高效、高质量地向用户交付软件。典型的 DevOps 流程波及一系列步骤,例如写代码、构建、测试和部署。DevOps 通过自动化、版本控制、剖析和报告来帮忙治理构建和测试。  而 FinOps 是一个专一于财务经营的流程,其指标在于促成财务和经营团队之间的合作和效率。FinOps 通过激励两个团队的合作、沟通和整合,来弥合财务和经营团队之间的空缺。FinOps 旨在创立一个更麻利、更高效的流程来治理企业的财务经营,并自动化流程并缩小实现工作所需的手动工作量。  DevOps 和 FinOps 之间的差别在这个日益数字化的时代,DevOps 和 FinOps 的作用变得比以往任何时候更加重要。DevOps 和 FinOps 在软件开发过程中各有千秋,但两者之间存在要害差别。以下是 FinOps 和 DevOps 之间的 9 大区别:  指标:DevOps 专一于进步开发和部署速度和品质,而 FinOps 专一于优化整个软件开发过程的效率和老本效益。工具:DevOps 工具旨在帮忙简化开发和部署过程,而 FinOps 工具旨在通过治理软件开发过程的估算、资源和其余财务方面来帮忙优化老本。工作流程:DevOps 侧重于继续集成、继续交付和自动化,而 FinOps 侧重于老本优化和财务管理。关注范畴:DevOps 关注软件开发过程和相干技术,而 FinOps 关注与开发过程相干的总体老本。团队组成:DevOps 团队通常由开发人员、工程师和系统管理员组成,而 FinOps 团队由财务业余人员和分析师组成。技能需要:DevOps 须要写代码、脚本编写和自动化等技术要求,而 FinOps 须要估算、预测和老本优化等财务能力。文化氛围:DevOps 专一于合作和试验,而 FinOps 则专一于老本优化和财务规定。观注点:DevOps 关注开发和部署过程,而 FinOps 关注开发过程的整体财务健康状况。衡量标准:DevOps 关注部署频率、交付周期和代码覆盖率等指标,而 FinOps 关注每次部署老本、总领有老本和投资回报率等指标。 DevOps 和 FinOps 对于胜利的软件开发我的项目都是必不可少的。通过理解两者之间的差别,企业组织可能确保优化其开发过程以实现最大效率和老本效益。  ...

February 27, 2023 · 1 min · jiezi

关于devops:研发效能DevOps推荐书单

专一 300 页之内的经典书籍举荐 研发效力波及的常识很多,从大的方向去划分包含制度、组织、平台、经营等;单从软件研发的角度去看也包含很多,包含最底层的软工认知、实际,到团队治理和组织、麻利研发,项目管理、源码治理、公布治理、可观测性,到产品的经营和反馈。 当初很多公司曾经组建了或者正在组建研发效力团队,每个人都大略有个认知,然而具体又很难说清本人该做什么不做什么,找不到本人的外围价值。「就菜下锅」「看碟下菜」是一种策略,然而我集体感觉还是要从大方向上对研发效力有个清晰的认知,分清边界、高效协同。 如果你对这个方向感兴趣,无妨有空的时候翻一下下面举荐的书籍,读有所得。 我的相干文章研发效力|DevOps 已死平台工程永存带来的焦虑如何疾速晋升团队软件开发成熟度,晋升研发效力?什么是研发效力?研发效力定义及外围价值研发效力生态残缺图谱&DevOps工具选型必看互联网公司研发效力/工程效率团队建设和布局感激点赞、转载关注我,理解研发效力倒退动向关注我,关注「DevOps研发效力」一起探讨

February 23, 2023 · 1 min · jiezi

关于devops:利用唯一可信源加速DevOps发布

February 17, 2023 · 0 min · jiezi

关于devops:4道数学题求解极狐GitLab-CI-流水线|第23题父子流水线-多项目流水线

本文来自:武让 极狐(GitLab) 高级解决方案架构师 极狐GitLab CI 依附其一体化、轻量化、申明式、开箱即用的个性,在开发者群体中的使用率越来越高,在国内企业中仅次于 Jenkins ,排在第二位。 极狐GitLab 流水线有 4 种不同类型,别离是: 有向无环图流水线父子流水线多我的项目流水线合并列车 但仅靠这些流水线类型名称和官网形容,咱们很难了解其意义和用处。因而,作者联合泛滥用户反馈和本身实际,简明扼要 “从新定义” 了这些流水线类型,并通过 3 篇连载文章为您解答,帮忙您把握极狐GitLab 流水线。 第 1 篇分享了有向无环图流水线 。 本文是第 2 篇——父子流水线 + 多我的项目流水线 ,enjoy~ 父子流水线 Parent-Child Pipelines1. 官网定义Parent-Child Pipelines 即父子流水线,它和 Multi-Project Pipelines 多我的项目流水线都属于上游流水线。所谓上游流水线: 由另一个流水线触发的任何极狐GitLab CI/CD 流水线。它能够是: 一个父子流水线,是与第一个流水线在同一个我的项目(代码库)中触发的上游流水线;多我的项目流水线,是在与第一个流水线不同的我的项目(代码库)中触发的上游流水线。父子流水线,官网定义和介绍如下: 父流水线是在同一我的项目(代码库)中触发上游流水线的流水线,上游流水线称为子流水线。 子流水线依然依据阶段程序执行他们的每个工作,但能够自在地持续他们的阶段,而无需期待父流水线中不相干的工作实现;该配置被拆分为更小的子流水线配置。每个子流水线只蕴含更容易了解的相干步骤,缩小了了解整体配置的认知累赘;导入在子流水线级别实现,缩小了抵触的可能性。这个解释比 DAG 流水线要容易了解一些,然而咱们仍然能够换一种比拟接地气的形式进行从新形容。 2. 从新定义父子流水线解决一个判断题+选择题。 次要性能: (按条件触发并)执行同一个我的项目(代码库)中不同的流水线脚本。3. 问题解答接着第 1 篇 有向无环图流水线 中的问题 1 持续,还是那个跨平台我的项目。 问题 2如果当初 iOS 平台利用有一些 Bug,开发人员仅对 iOS 局部代码进行了批改,而后心愿编译打包 iOS 平台利用并公布上线。但不心愿再次打包 PC 和 Android 平台,浪费时间和资源,怎么办?如果是个通用问题,在 3 个平台上都呈现了,那么批改通用局部代码后还须要同时打包 3 个平台的利用,又该怎么办?这个跨平台我的项目文件目录如下: - common  - code_files...  - .gitlab-ci.yaml #全副平台构建打包脚本- android  - code_files...  - .gitlab-ci.yaml  #Android平台构建打包脚本- ios  - code_files...  - .gitlab-ci.yaml #iOS平台构建打包脚本- pc  - code_files...  - .gitlab-ci.yaml #pc平台构建打包脚本为了解决这个问题,就须要应用到父子流水线,次要会应用到 rules:is:changes 和 trigger 关键字,用来实现按条件触发,而后执行不同流水线脚本,比方: stages:  - build  - triggersandroid_trigger:  stage: triggers  # 当android目录下的文件发生变化时触发  rules:    - if:       changes:        - android/*  # 触发执行android/.gitlab-ci.yml脚本  trigger:    include: android/.gitlab-ci.yml    strategy: depend  ios_trigger:  stage: triggers  # 当ios目录下的文件发生变化时触发  rules:    - if:       changes:        - ios/*  # 触发执行ios/.gitlab-ci.yml脚本  trigger:    include: ios/.gitlab-ci.yml    strategy: depend  pc_trigger:  stage: triggers  # 当pc目录下的文件发生变化时触发  rules:    - if:      changes:        - pc/*  # 触发执行pc/.gitlab-ci.yml脚本  trigger:    include: pc/.gitlab-ci.yml    strategy: dependcommon_build:  stage: build  script:      - echo "common build"  # 当common目录下的文件发生变化时触发,执行默认的根目录.gitlab-ci.yml脚本  rules:    - changes:      - common/*当批改 iOS 目录文件后,只触发了 ios/.gitlab-ci.yml 脚本的执行。 ...

February 17, 2023 · 1 min · jiezi

关于devops:现代化汽车行业软件开发与管理

随着汽车上电子控制器品种和数量的逐步减少,软件品种和软件版本也会逐步增多。为了保障产品品质,汽车企业必须对车辆上的软件版本进行治理,以确保车辆在应用过程中不会呈现品质问题。同时软件源码是企业的外围资产,随着软件在汽车上施展的作用越来越大,要害的技术内容都会被形象为软件性能,源码对于汽车企业来说会越来越重要。汽车软件将会是汽车要害核心技术的次要载体,汽车企业们岂但要在软件源码治理上下功夫,还须要在软件定义和开发上下功夫。2月22日,ATC汽车技术平台联结JFrog独特举办“现代化汽车行业软件开发与治理”直播流动,流动特邀吉利汽车、JFrog技术专家分享OEM软件品质面临的挑战、车企软件开发与治理教训,大型车企在软件制品库治理上的应用教训及解决方案,欢送大家关注并加入!  流动工夫:2月22日 15:00-16:30流动模式:线上直播嘉宾介绍 窦国伟/吉利汽车研究院总院软件系统利用专家领有15年的新能源汽车(BEV/PHEV/FCEV)能源及电控零碎开发实战经验,次要负责能源电控系统集成、控制软件开发、测试及标定工作。把握整车性能属性、动力系统架构、高低压电气系统、整车管制软件架构及设计、软件集成及品质测试等新能源汽车核心技术,具备ISO26262性能平安及ASPICE流程体系建设教训。在大型当先主机厂和电动汽车公司主导开发了近十款新能源汽车我的项目。 王青/JFrog (中国) 技术总监十五年麻利研发治理与软件工程实践经验,目前任 JFrog 中国技术团队负责人。ArchSummit,GOPS金牌讲师,屡次在国内各大技术社区发表文章和演讲,例如 InfoQ,高效运维社区,51CTO 等等。专一于微服务架构,继续集成,继续交付,DevOps,容器化平台建设等等。  流动议程15:00-15:05  主持人收场15:05-15:35  OEM软件品质面临的挑战——窦国伟 吉利汽车研究院总院软件系统利用专家15:35-15:40  问题解答15:40-15:45  第一轮互动抽奖15:45-16:20  JFrog助力车企实现现代化软件制品治理的建设——王青 JFrog (中国) 技术总监16:20-16:25  问题解答16:25-16:30  第二轮互动抽奖、完结  报名形式扫描二维码,即可报名参会。

February 16, 2023 · 1 min · jiezi

关于devops:4道数学题求出极狐GitLab-CI-流水线之最优解|第1题有向无环图流水线

本文来自:武让 极狐GitLab 高级解决方案架构师 极狐GitLab CI 依附其一体化、轻量化、申明式、开箱即用的个性,在开发者群体中的使用率越来越高,在国内企业中仅次于 Jenkins ,排在第二位。 极狐GitLab 流水线有 4 种不同类型,别离是: 有向无环图流水线父子流水线多我的项目流水线合并列车 事实上,仅靠这些流水线类型名称和官网形容,咱们很难了解其意义和用处。 因而,作者联合泛滥用户反馈和本身实际,简明扼要 “从新定义” 了这些流水线类型: 有向无环流水线,是一个数学题;父子流水线,是一个判断题+选择题;多我的项目流水线,是一个排列组合题;合并列车,须要追溯其起源,弄清楚合并申请流水线、合并后果流水线和合并列车。何以言之?接下来,咱们将通过 3 篇连载文章为您解答,帮忙您把握极狐GitLab CI 流水线。 本文为第1篇——有向无环图流水线 ,enjoy~ 有向无环图流水线 DAG Pipelines1. 官网定义DAG Pipelines 全称是 Directed Acyclic Graph Pipelines,即有向无环图流水线,官网定义和介绍如下: 有向无环图能够在 CI/CD 流水线上下文中,用于在作业之间建设关系,以便以最快的形式执行,无论阶段如何设置;例如,您可能领有作为次要我的项目的一部分而构建的特定工具或独自网站。应用 DAG,您能够指定这些作业之间的关系,零碎会尽快执行作业,而不是期待每个阶段实现。并附上了一个不明觉厉的图: 置信这段介绍曾经击败了 95% 的初学者,那 DAG 流水线到底是什么?它用在什么场景解决什么样的问题? 2. 从新定义DAG 流水线解决一个数学题。 次要性能: 打消木桶效应,升高构建工夫,进步构建效率;对流水线 Job 进行编排。这段介绍绝对比拟简洁了,但要了解 DAG 流水线,还须要开展来看看这个数学题是什么,以及 DAG 是怎么解决问题的。 开展这个问题前,有些根底概念比方 Runner、Stage、Job 就不再复述了,如果对这些概念不理解,倡议先学习极狐GitLab CI 入门常识,能够参考: GitLab CI/CD 入门 | 极狐GitLabCI/CD从入门到实际:yml语法、罕用变量、Runner装置配置3. 问题解答问题1-1假如有一个跨平台我的项目,它通过极狐GitLab CI 别离实现 Android、iOS、PC 三个平台的构建、测试和打包。流水线的 Stage 和 Job 如下所示,Job 中标识了该 Job 执行所需工夫。疏忽所有 Job 的启动工夫,问 PC 平台打包需多长时间?Android 平台打包需多长时间? ...

February 9, 2023 · 1 min · jiezi

关于devops:DevopsCamp-第一期作业-cobra-01-实现编译与参数绑定简单-解题答案

DevopsCamp 第一期作业: 《cobra - 01 实现编译与参数绑定(简略)》 解题答案原文链接: https://tangx.in/posts/2023/0...本文为 DevOpsCamp 实战训练的作业解题答案 作业: cobra - 01 实现编译与参数绑定。 DevOpsCamp作业地址: https://www.devopscamp.cc/sem...作业要求:应用 https://github.com/spf13/cobra 实现命令工具命令具备以下参数 --name 姓名--age 年龄如果年龄为空, 默认为 20 岁。实现穿插编译脚本, 编译其余平台的二进制文件-rwxr-xr-x 1 franktang staff 4220672 Jan 13 15:35 greeting-darwin-amd64-rwxr-xr-x 1 franktang staff 4203442 Jan 13 15:35 greeting-darwin-arm64-rwxr-xr-x 1 franktang staff 4215010 Jan 13 15:35 greeting-linux-amd64-rwxr-xr-x 1 franktang staff 4157892 Jan 13 15:35 greeting-linux-arm64执行输入成果如下$ ./out/greeting-darwin-arm64 你好, 往年 20 岁$ ./out/greeting-darwin-arm64 --age 30 --name zhangsanzhangsan 你好, 往年 30 岁解题过程1. 装置依赖包$ go get -u github.com/spf13/cobra2. 创立命令var root = &cobra.Command{ Use: "greeting", // 命令名字 Short: "打招呼", // 短介绍 Run: func(cmd *cobra.Command, args []string) { // 运行函数 greeting(name, age) },}3. 指定参数定义了变量作为参数接受者。应用 init 函数, 在程序初始化的时候, 传递参数值。 ...

January 29, 2023 · 2 min · jiezi

关于devops:DevOps-如何帮助实现安全部署

DevOps 是一种强调团队之间沟通和合作的软件开发办法。最显著的特点是将以前在工程或测试等不同畛域工作过的人和流程汇集在一起,使得在一起做我的项目的时候能够相互合作和学习。 DevSecOps 可帮忙组织在整个开发过程中监控和发现平安危险,而不是在公布后的保护措施上破费大量资金和精力。通过这种形式可能爱护产品,而不会让开发人员承当过多的责任。 PART 01 DevSecOps的指标DevSecOps 的指标是在不影响团队生产力的状况下提供平安最佳实际。平安开发是顺利部署过程的要害。当产品中存在平安方面的隐患,但却没有失去很好的解决,这无疑为当前减少了平安危险和更繁琐的解决形式。DevSecOps 通过揭示每个人良好的平安习惯对开发人员和运维人员来说都十分必要。 为了使平安更加无效和牢靠,应该从一开始就将平安其纳入开发当中。这意味着,与其等到问题或危机呈现时才施行保护措施,如防火墙、加密密钥等,不如在开发期间就事后解决这些平安问题,以便在前期能更好的运行。 它有助于确保在过程中尽可能早地发现平安问题,从而及时失去解决。当平安问题在仍我的项目刚完结时失去解决,就比在前期返回从新修复容易的多。 PART 02DevSecOps 的劣势对于任何想要在这个数字时代生存上来的公司来说,平安都应该是重中之重。从升高危险到加重法律责任,在软件开发生命周期的晚期辨认缺点,能够在呈现问题时更轻松地进行平安治理。如果将重点转移到流程的晚期,那么会比在前期解决付出的代价更低。 DevSecOps 的指标是为开发人员和运维人员提供对于他们正在进行的工作更快的反馈,以便他们可能立刻失去告诉并进行调整和修复。 PART 03实现 DevSevOps在施行 DevSecOps 时,没有一个对立的规范和标准,因为每个组织的需要都是举世无双的。但有一些常见的做法。 ① 取得管理层的反对要从根本上扭转组织思考、构建和部署软件的形式,须要的不仅仅是点对点协定。对于这种革命性的思维形式转变,管理层的反对是必要的。DevSecOps 过程能够帮忙缩小在生产中呈现被利用的软件破绽。对于那些在危险和收益之间做决定的人来说,重要的是要看到这将如何使公司受害。 ② 开发人员责任DevSecOps 流程器重安全性并使其成为开发过程的一部分,而不是预先才思考的事件。整个团队能够协同工作来编写更平安的代码和配置,这些代码和配置可能抵挡威逼,同时在呈现谬误时也能够很容易地复原。 这也不再只是平安业余人员的工作。它须要每个人都参加爱护本人的工作局部的安全性,而不是冀望他人来做。 PART 04平安和 DevSecOps 培训通过培训,让每个人都理解 DevSecOps 办法,他们不仅会了解它为什么重要,而且还会看到如何正确实现这种新的工作模式。 PART 05应用适当的工具和流程并非只有一种正确的办法来实现 DevSecOps ,每个组织都有本人独特的构建软件的办法,当在不同文化和工作场合的不同组织中实现这些概念时,须要思考这些办法。通常状况下,动态利用平安测试工具,动静利用平安测试工具,软件成分剖析及交互式平安测试工具等自动化工具是常见的在 DevSecOps 中应用的工具。其中还包含一些自动化构建工具和缺点管理工具等。 通过向开发管道引入新的平安组件,DevSecOps 正在用 DevOps 最佳实际扩大咱们的根本开发和经营组件。DevSecOps 在软件开发中确保了平安危险在所有阶段都失去监控,而不是只在公布之后才修复破绽和 bug,在破绽被利用后再修复就为时已晚。 作者:中科天齐软件源代码平安检测核心文章起源:https://devops.com/how-devops-helps-with-secure-deployments/文章转自:https://jishuin.proginn.com/p/763bfbd7faa7

January 4, 2023 · 1 min · jiezi

关于devops:阿里云联合产学研媒发起BizDevOps共促计划助力企业提升组织效能

2012年寰球最具影响力的独立钻研咨询机构Forrester曾预言:“In the future, all companies will be software companies”(在将来,所有的企业都将成为软件企业) 近10年来,DevOps静止在寰球和中国风起云涌,已成为软件产业先进生产力的代表。然而,DevOps将关注点次要放在突破开发与运维之间的壁垒,尽管极大地晋升了软件的研发运维效率,但尚未造成残缺的价值闭环。BizDevOps提倡开发与运维之间的整合向前进一步扩大延长到业务,使能业务作为价值的终点及外围指标,充沛、高效地对接到DevOps的价值实现引擎。 阿里云联结产学研媒 首发必致(BizDevOps)白皮书12月22日,2022阿里云研发效力峰在线上举办,会上阿里巴巴副总裁、阿里云根底产品事业部总经理蒋江伟发表,阿里云与南京大学、招商银行、思特沃克、极客邦等“产学研媒”联结发动BizDevOps共促打算。共促打算旨在突破业务、开发与运维之间的壁垒,助力企业晋升组织效力,聚焦BizDevOps技术体系的欠缺、利用与推广,减速企业的数字化转型。 BizDevOps白皮书首发 白皮书下载地址:https://developer.aliyun.com/ebook/7847 《必致(BizDevOps)白皮书》提出1个指标、3个能力和5个要害实际,理清对BizDevOps的明确定义,达成独特认知;在此基础上,建设起BizDevOps的概念模型和实际体系,为国内企业和实践者勾绘出BizDevOps方向的第一张施行路线图。 BizDevOps共促打算成立官宣 阿里云负责理事长单位BizDevOps共促打算正式成立于往年8月份,是由阿里云计算有限公司联结南京大学软件研发效力实验室、思特沃克软件技术(北京)有限公司、中国信息通信研究院、北京极客邦科技有限公司、招商银行股份有限公司、上海优川信息技术有限公司独特成立的专业性、全国性、非营利性的虚构社会组织。《必致(BizDevOps)白皮书》是BizDevOps共促打算组织孵化的第一个重磅成绩。 阿里云计算有限公司被推举为第一届理事长单位。作为BizDevOps共促打算的理事长单位代表,阿里巴巴团体副总裁、阿里云根底产品事业部总经理蒋江伟此次于阿里云研发效力峰会·主论坛上,正式官宣BizDevOps共促打算组织的成立,并发表组织继续面向相干企事业单位、高等院校、科研院所、社团组织凋谢共建。主论坛后,曾经陆续有多家企业表白冀望一起共建。 产学研媒独特成立BizDevOps共促打算 阿里云云效全面撑持BizDevOps实际,向晋升效力进化云效作为阿里云计算有限公司在BizDevOps共促打算中的外围代表,本次在大会重磅公布全面撑持BizDevOps实际的产品能力,包含业务驱动的组织协同机制,产品导向的团队组织和交付形式、利用为外围的研发资产和流程治理、适配业务特色的继续业务交付,以及两头的全量、全因素、实时数据反对的度量和继续改良实际。 云效全面撑持 BizDevOps 5大实际 阿里云云效负责人陈鑫示意,《必致(BizDevOps)白皮书》中定义的BizDevOps数据模型,代表了BizDevOps共促打算全体成员对业产技协同最外围因素的了解,以及这些因素之间的连贯。通过面向价值而不是面向流程的数据模型,咱们就有机会去洞察每一个价值发明过程的时效与阻塞,也就有机会真正的做到价值流剖析。在过来咱们短少面向价值的视角,短少价值链路的残缺连贯,短少数据的积淀与剖析能力,让咱们始终无奈精确答复对于研发效力改良带来的业务价值交付效率晋升的问题,无奈将效率转化为经营效益。而解决这个痛点正是BizDevOps数据模型和分析方法的指标。 BizDevOps数据模型驱动继续改良 最初,陈鑫认为,团队要实现BizDevOps,须要落地好三大部分。 第一,致力突破业务与产研的部门墙,与业务团队一起做好“定义价值”这个阶段。业务确定市场机会,设定业务指标,与产研廓清需要内容,做好需要价值评估,这个阶段的争执会十分有意义,一旦进入下一个阶段再掉头批改会付出昂扬老本。 第二是“个体发明价值”阶段,业产技三者做好需要分层,产品设计、技术研发,将所有流动线上化并连贯在一起。指标的通明、决策的通明、工作的通明会让“个体发明价值”的协同更加高效,最大水平的缩小信息衰减带来的谬误和节约。 第三是“继续学习”阶段,通过数字化的办法去设定指标找到瓶颈,一直优化各角色业余能力、工作流程、资源配置等。将组织效率定量出现,激发组织继续改良。 实现BizDevOps的三个阶段 原文链接 本文为阿里云原创内容,未经容许不得转载。

December 26, 2022 · 1 min · jiezi

关于devops:什么是DevSecOps理解DevOps安全性

明天,大多数组织曾经采纳了 DevOps 实际,这些实际有助于自动化,提供了一种团队能够集成流程的文化,并且应该可能以更快的形式交付牢靠的软件和更新。随着对软件应用程序需要的一直增长,对扩大的需要也随之增长,这反过来又导致了安全漏洞和威逼。因而,对于 DevOps 团队来说,在软件开发周期工作流的每个阶段增加安全措施变得十分重要。平安问题应失去比以往任何时候都更高的优先位置。提供一种文化,使团队可能集成流程,并且应该可能以更快的形式交付牢靠的软件和更新。因为随着软件应用需要的一直增长,对扩大的需要也随之增长,这反过来又会导致安全漏洞和威逼。因而,对 DevOps 团队来说,在软件开发周期工作流程的每个阶段都退出安全措施变得十分重要,安全性应该失去比以往任何时候都更高的优先级。 一、DevOps(DevSecOps)中的安全性是什么?DevSecOps 或 DevOps 中的安全性是一套实际、文化和性能办法,以及一套 DevOps 平安工具,在这些工具中,咱们将开发、操作和安全性联合在一起,以高效和平安的形式交付应用程序和服务。通过 DevSecOps,安全性被注入到继续集成和间断交付(CI/CD)管道中,这有助于开发人员解决平安问题。 早些时候,在软件开发生命周期完结时引入了平安思考,这导致了网络安全攻打的减少,开发团队正在为利用程序开发更频繁的版本修复。上面的文章分享了将安全性利用于 DevOps 环境的根本注意事项,并提供了 DevOps 平安挑战和最佳实际的概述。本文介绍了将安全性利用于 DevOps 环境的根本思考事项,并概述了 DevOps 平安挑战和最佳实际。 二、DevOps 的平安挑战是什么?实现 DevOps 安全性带来了几个挑战。从一个大的组织到小的组织,咱们在任何中央都能够看到平安采纳方面的奋斗和挑战。DevOps 平安挑战分为技术、人员、工具等。咱们将理解团队面临的大多数挑战: 文化变迁对于任何人来说,引入一种新的办法并进行文化转换是相当具备挑战性的,特地是如果它须要正确的 DevOps 平安办法和思维转变,将平安作为软件开发中思考的第一步。此外,平安团队次要关注应用程序的安全性,以便环境和代码应该是平安的,而开发人员则关注于开发和因为及时性而放慢交付。意见和指标的不同导致了操作摩擦,这对今后的倒退具备很大的挑战性。 这能够通过让来自安全性和开发人员的人员参加到独特的实际中来解决,并独特朝着一个对立的指标致力。人们冀望代码可能更快、更平安地交付。 云的复杂性许多组织正在应用多个云来进步管理效率,利用最佳的云解决方案和多重自动化的实现,这使得平安设置成为团队十分具备挑战性的工作。 不足技能和常识专业技能和常识在施行 DevOps 实际中也起着关键作用。不足平安实现技能成为团队在 DevOps 管道中实现安全性的阻碍。 对 DevOps 和 DevOps cyber security 中的平安工具相干的员工进行外部培训能够帮忙他们取得 DevOps 平安模型的常识并进步意识,从而为团队造就更有教训的 DevOps 平安工程师,并进一步成为领导其余团队成员的机会。 工具集成有余和简单动态利用平安测试(SAST)和软件组合分析(SCA)对晚期状态破绽的检测十分有帮忙,但不反对更快的部署和较长的运行工夫,因而开发人员偏向于防止将工具集成到应用程序中。此外,当平安工具须要与不同的 DevOps 工具集成时,场景会变得更加简单。 找到一个能够解决平安问题的工具,或者应用更多的 clouddevops 平安服务来防止 SAST 和 SCA 工具的问题,这将很有帮忙。 角色与责任不匹配将 DevOps 和平安团队的角色和职责协调起来是十分具备挑战性的。首先,次要关注点是更快的公布和部署,而平安团队则专一于确保 DevOps 的平安实际,这就造成了安全性和 DevOps 之间的不兼容性。须要 DevOps 的平安实际和零碎是平安的,放弃可追溯性,容错,并解决问题。但因为文化的转变,它变得具备挑战性,这一点在上文中也曾经探讨过。 DevOps 安全检查表中最好的办法之一是向左挪动,即在软件开发生命周期(SDLC)中将 DevOps 平安实际移到更早的地位,这样开发人员就能够及早发现平安问题。 ...

December 24, 2022 · 2 min · jiezi

关于devops:金融科技-DevOps-的最佳实践

随着软件技术的倒退,越来越多的企业曾经开始意识到 DevOps 文化的重要价值。DevOps 可能打消扭转公司业务发展形式,并以更快的速度实现交付,同时创立迭代反馈循环以实现继续改良。而对于金融科技(FinTech)行业来说,领有一套企业量身定制的 DevOps 流程变得至关重要。因为 FinTech 企业须要在应答一直变动的监管和平安场景的同时为客户提供翻新价值,而领有并施行以 FinTech 为核心的 DevOps 办法对 FinTech 企业的业务胜利来说非常要害。  本文将谈谈 DevOps 如何融入金融科技世界。并一起探讨 FinTech 公司在倒退独特的 DevOps 文化和工程实际时能够采纳的办法与最佳实际。  FinTech 行业的不同之处传统软件行业正在飞速变动,而对于 FinTech 畛域来说倒退速度甚至更放慢。FinTech 是一个绝对较新的畛域,却又在最古老的畛域之一——金融服务中运作着,而古代技术的提高以及一直变动的消费者冀望要求企业须要一直响应。因而企业想要在 FinTech 畛域中怀才不遇,在倒退无效且个性化的 DevOps 文化时,须要考虑一下两个对 Fintech 行业的独特因素。  消费者驱动的市场变动随着消费者对软件技术的认知与承受,人们开始要求越来越简单的金融科技解决方案来解决在过来几十年甚至几个世纪以来始终由人工执行的财务工作。例如,金融科技服务正在席卷房地产行业。在2022 年福布斯金融科技 50 强上市公司中,有五家金融科技公司属于房地产行业。从提供投资出租物业的新形式到颠覆当今购房者的抵押贷款体验,消费者们要求在房地产投资和抵押贷款方面取得与他们在惯例销售点和集体银行服务中所冀望的雷同的易用性,房地产金融科技受到年轻人群需要的推动。  立法驱动的监管需要金融科技领域的变动由监管环境驱动。寰球现行的大部分立法都是为金融行业制订的。当政府试图协调金融法与金融科技公司提供的翻新金融产品和服务时,他们会一直钻研新产品。因而,金融科技公司常常发现自己须要在翻新步调与监管思考之间获得均衡。  不言而喻,金融科技领域的公司不同于个别的软件公司。其商业环境的特殊性决定了企业外部流程的独特性。这其中就包含 DevOps。DevOps 通过应用自动化和反馈来疾速向客户交付价值,对于任何软件公司的策略来说都是必不可少的。而对于金融科技公司所处的非凡畛域,在施行 DevOps 时须要思考金融行业法规因素。  独特的 FinTech DevOps 文化采纳 DevOps 办法会影响公司的开发人员 DevOps 文化及其实际。在金融科技公司中,以下提到的 DevOps 文化元素应该受到特地关注。  扩散所有权FinTech 企业须要思考的 DevOps 文化元素是“去中心化所有权”的概念。为了可能灵便无效地响应一直变动的消费者需要和法规,特定产品性能或基础设施要求的所有权不能独自隔离开来。因而,任何辨认出要害需要或工作的有能力的员工或团队都应该被受权和激励以独立于组织构造或严格的工作框架来解决问题。  器重自我批评FinTech DevOps 的另一个重要元素是强调自我批评的价值。如果企业的 DevOps 不容许或激励团队检查和反思他们在呈现问题时所表演的角色,企业将无奈翻新或做出足够快的响应以应答突发事件。  应急意识与准备计划随着金融科技服务对古代消费者变得越来越重要,金融科技公司将越来越多地成为平安威逼的指标。成熟的团队该当采取一种安全策略来为可能产生的歹意攻打做筹备,这种态势也将影响企业对软件开发生命周期 (SDLC) 和 DevOps 策略的打算与施行。  FinTech DevOps 最佳实际在这一部分咱们将探讨 FinTech DevOps 的最佳实际。  ...

December 23, 2022 · 1 min · jiezi

关于devops:为什么数字化时代需要-BizDevOps

随着云原生、元宇宙、Web3等技术拉开序幕,智能制作、智慧城市、精准医疗等利用场景徐徐开展,继人类工业文化之后,下一个大变局的奇点邻近。 毫无疑问,以数字技术利用为主线的数字化转型是此次人类文明改革的外围能源。在这一改革过程中,技术与业务的关系正产生根本性的转变,技术开发和交付形式也随之降级。 图片信息化-互联网经济-数字经济时代,技术和业务关系继续变动,开发和交付形式也随之演进 上图回顾了中国改革开放40多年所经验的次要阶段,业务与技术之间关系的转变,以及这一关系所催生的技术交付模式的改革。 (信息化辅助的)工业化阶段工业化的过程让中国制作从作坊变成了高度自动化的流水线。信息技术在其中起到了推动和撑持作用,OA(办公自动化)、ERP(企业资源布局)、金融信息系统,以及各类MIS(管理信息系统)让先进的治理理念和规定得以落地,让各个环节的经营效率成倍晋升,成就了具备国内竞争力的产业集群。 在工业化阶段,技术(次要是IT技术)与业务绝对独立,并撑持业务。如图中所示,此时IT技术与业务还是绝对独立的。与之对应,IT开发与交付的特色是:业务与开发绝对独立——拆散的技术团队承受来自业务的明确需要;开发与运维绝对独立——开发实现后,由运维团队集中统一部署施行。 绝对“软件作坊”,瀑布模式代表了先进生产方式,是工业时代开发和交付的支流模式。瀑布模式强调各个阶段(如:需要、开发、测试、部署)界线和职责明显,寻求确定的打算和执行。在工业化阶段,这是正当和可行的,而信息化也为工业时代提供了极大助力。 互联网阶段上世纪末开始,互联网技术的利用首先带来服务业全面降级,从娱乐、征询,到购物、金融、再到教育、政务,都产生了颠覆式的变动。如图中所示,此时的技术与业务开始互相联合,并催生了电商、互联网金融、生存服务等新的商业模式。 互联网成为社会经济的重要组成部分。在互联网经济下,技术成为业务倒退的重要变量,业务的不确定性大为晋升。业务与技术的界线开始含糊,小步快跑、疾速迭代、反馈试错等成为业务和技术的独特谋求。此时,麻利和精益开发模式登上舞台,逐步占据支流,强调业务与技术更严密合作的精益守业理念也被宽泛承受。 在这一阶段的IT开发和交付办法的集大成者非DevOps(开发运维一体化)莫属。它以零碎的实际突破开发和运维的边界,构建起疾速开发、交付和反馈闭环,大大减速了从产品想法到客户反馈的闭环。DevOps静止中,卓越互联网产品团队一天能够实现几十上百次这样的验证闭环。DevOps指引了互联网时代IT开发和交付办法的演进方向,也奠定了数字化时代技术交付办法的根底。 数字化阶段时代的科技车轮减速后退,站在当下的数字化时代,数字经济正沿着产业数字化和数字产业化这两大主题高速演进。 一方面,技术的前沿一直向前推动:从IoT到机器人,从区块链到Web3,从云原生到量子计算,从5G到边缘计算,从虚拟现实到元宇宙,让人应接不暇;另一方面,数字技术减速融入并粗浅扭转每一个产业,各行各业的价值链被数字技术重塑,数字化转型成为各行各业的共识。 利用数字技术,重塑业务价值链,晋升价值交付的效率、品质和体验,这是数字化转型的实质。数字化时代,所有业务都将运行在数字化技术之上。正如上图所示,技术将成为业务的内核,业务的进化与技术的进化成为一体。 这令人兴奋,同时也带来了组织的个体焦虑 —— 如何保障数字化转型资源投入的有效性成为组织倒退的外围命题。 在产业数字化的趋势下,技术成为业务演进和翻新的内核。业务和技术的单干关系也亟需降级,突破点在于打造业务与技术深度交融的组织机制与实际办法,而这一办法就是BizDevOps。 咱们将BizDevOps的中文称为“必致”,一方面是“Biz”的音译,体现了服务于业务数字化转型的外围指标;另一方面是为了表白打造业务技术交融的组织和办法体系,行稳致远,以撑持数字化转型这一指标的达成为长期使命。 BizDevOps中文“必致”释义 原文链接 本文为阿里云原创内容,未经容许不得转载。

December 19, 2022 · 1 min · jiezi

关于devops:2023年-DevOps-七大趋势

随着工夫的推移,很显著 DevOps 曾经成为最高效的麻利框架中的无人不知晓的名字。越来越多的企业(包含各类规模企业)正在采纳 DevOps 办法来简化其经营效率。DevOps 的新时代趋势曾经见证了其使用率的持续上升。  因为需要的变动和古代软件的复杂性,现在的公司须要各种各样的平台和操作系统,因而 DevOps 更多的是将企业推向更高的高度并利用技术帮忙企业实现商业指标和价值。DevOps 中的最新技术趋势基于最佳实际,帮忙推动企业在数字化提高驱动的古代经济中的绩效。一起来看看在将来一年,DevOps 的发展趋势是怎么的。  1. DevSecOps随着平安成为数字时代最重要的问题之一,企业曾经整合了 DevSecOps 生命周期,从而进一步强化平安,同时 DevSecOps 也被用于简化治理和进步可见性。DevSecOps 的次要思维是平安应该遵循的“左移”办法,而不是预先修复和补救。依据最新的 DevSecOps 趋势,大概 40% 的企业有在应用 DAST 测试,50% 在应用 SAST,其余的企业通过扫描依赖项和容器来确保软件平安。   有一个十分典型“平安左移”例子与大家分享,就是 Pokemon Go。Pokemon Go 在首次推出时就开始呈现用户隐衷责任问题,因为寰球未成年人用户的下载量超过 8 亿次,他们有责任依据 GDPR(General Data Protection Regulation)规定爱护用户隐衷。随即,Pokemon go 与 Niantic 合作开发,并与 Niantic 独特承当平安合规性和开发方面的责任。Pokemon Go 承当了肯定比例的儿童保育平安合规性以及后端操作,但整个应用程序都由 Niantic 治理。因为存在大量的独特责任和第三方数据,灌输合作和平安文化成为必要措施,在安全检查方面采纳 DevSecOps 集成自动化,而不是从第一阶段开始手动监控应用程序隐衷。   2. 无服务器计算无服务器计算(Serverless Computing)是一种在不思考服务器的状况下开发和运行服务和应用程序的办法。这些应用程序不须要治理服务器,因为它们是从应用程序的开发阶段开始构建的。多年来,它已成为一种宽泛应用的软件部署翻新办法。事实上,到 2030 年,无服务器市场预计将达到 300 亿美元。此外,超过 50% 的领有基于云的课程的企业都在其零碎中集成了无服务器计算。   DevOps 过程极大地受害于无服务器计算方法。通过减少可操作性,它胜利地弥合了开发和经营之间的差距。它还有助于生成 DevOps 流水线代码,而无需 host 进行开发、测试和部署。  3. 微服务架构微服务架构(Microservice Architecture)通常被称为微服务,目前在IT畛域被宽泛应用。它通过定制以适应最新的 DevOps 市场趋势,已胜利将古老的宏大应用程序合成为更小的更易于治理的局部。胜利简化了开发测试以及经营中的部署。它还简化了软件和应用程序的统一和频繁交付。促成 DevOps 流程和准则以进步产品的整体品质变得更加容易和简略。  ...

November 29, 2022 · 1 min · jiezi

关于devops:无序和混乱终结者极狐-GitLab-Workflow-到底有什么魔力

效率和品质是软件产品谋求的两个外围关键点,软件产品研发是一个笼罩多阶段、波及多团队的过程,业界也曾经总结出了一些很好的实际,在保障研发效率的同时还能保障代码品质。比方代码提交标准、Code Review、代码准入、CI/CD。 然而因为不足卓有成效的研发流程标准,让上述实际在落地的时候往往流于形式、可有可无,让保证质量、晋升效率成为悬而难落的话题。而代码提交不标准、不同开发模式下代码审核与准入环节的缺失是导致品质与效率双双降落的重要起因。 所见非所得的代码提交代码变更提交信息可能让外界对所变更的代码有一个疾速、清晰的认知,能够初步判断出变更代码的类型(新 feature 上线、bug fix、文档修复等),变更代码的范畴(某个接口的增删改、某个性能的增删改等),不仅利于代码审核人员对于审核代码有一个初步认知,也有利于呈现问题之后的问题回溯,更重要的是有助于进步代码的可维护性。 代码提交标准是每个企业都在谋求实际的,但并非所有的企业都可能通过流程 + 工具将标准进行到底,尤其在我的项目须要紧急上线,bug 须要紧急修复时,上面的这种代码提价信息也就变得比拟常见了: 4deaaed (HEAD -> main) add new feature5224286 fix api bug2506aa2 fix typo70819a2 delete useless code看似懂了又仿佛没懂的代码提交信息折射出了不标准的代码提交带来的结果:所见非所得。 简略然而熵增的开发模式基于 “主” 分支的开发因为 git 应用的复杂性,当团队的 git 应用技巧(分支的治理、代码的回退等)达不到肯定水平时,在业务提交紧急时,git add && git commit && git push 就成了代码提交三步曲,变更代码被间接推送到主分支,走先提交再验证的流程。 这是看似快捷不便的代码提交会带来以下问题: 逐步失控的代码仓库代码都是间接推送到 “主” 分支,代码没有先通过验证就提交,容易导致有问题的代码被合并到主分支,主分支可能会随时被阻塞,难以保障主分支实时可用、可交付的状态。另外,在不做提交文件限度(比方 pem、jar、war 等)的状况下,随着性能的迭代,代码仓库就会 “爆仓”逐步失控。无奈保证质量的代码代码变更都是先提交再去验证(提交之后,在主线验证),在提交前或提交后都不做 Code Review,代码的品质是难以保障的,最终导致产品的整体品质降落。返工重大,耗时耗力代码提交到主分支上,验证不通过就须要返工进行故障查找和修复。因为不足提交前的充沛验证和审核,就会导致这种返工是频繁的、耗时耗力的。基于 “多” 分支的开发当然,随着团队对于 git branch 的相熟,基于 branch 的业务开发也成为被很多团队所采纳的开发模式。开发人员不论是上线新性能还是修复缺点,都是先创立一个新的分支,基于这个新分支实现代码变更,通过验证之后再合入主分支。 这种模式尽管可能让开发者之间 “互不烦扰” 的进行开发,也可能比上述基于 “骨干” 分支的开发,让 “骨干” 分支被阻塞的工夫大大缩短,然而仍旧存在代码品质无奈保障的问题,因为缺失了两个关键环节: 1. Code ReviewCode Review 是保障代码品质的无效一环。“只有眼睛多,bug 容易捉”,如果让其余同行人员对于代码变更进行 Review,不仅可能对于变更代码是否合乎业务逻辑做一些查看,还有可能发现一些潜在的缺点,并且将反馈间接反馈给代码提交者,在修复之后再进行代码提交。很多时候,这种 Review 可能是多个回合,对于代码品质的进步是十分重要的。 ...

November 22, 2022 · 1 min · jiezi

关于devops:静态WEB容器镜像最小化实践

在古代的B/S架构利用中,咱们会做前后端拆散,某些前端Web服务会将编译实现的动态文件放到一个web服务器进行部署。例如,我的博客也是基于Hugo编译的动态文件来进行部署的。 那在容器化部署模式下,咱们须要基于一个web服务的根底容器(镜像)将动态文件构建成站点或者Web服务的容器镜像来进行部署。在Docker开发最佳实际中,咱们应该尽量放弃镜像足够小(Size大小)。因而,咱们应该尽量抉择满足咱们需要的web服务根底镜像足够小。 大部分状况下,咱们会抉择Nginx作为咱们的web服务器,一开始我也是这么抉择的,因为社区在Docker Hub上为咱们提供了开箱即用的容器镜像,上面来看看我用来构建动态web服务的过程。 Nginx On Alpine咱们晓得在容器构建的实际中,咱们能够抉择基于AlpineLinux为散发零碎的镜像,其比其余(例如 ubuntu, centos等)的镜像会小很多。因而一开始咱们也是抉择基于Alpine的nginx镜像,例如 nginx:1.22-alpine。 $ docker image pull nginx:1.22-alpine$ docker image ls | grep nginxnginx 1.22-alpine 23.5MB能够看到其大小为 23.5MB 。 基于该惊醒构建我的博客的公布镜像 FROM mengzyou/hugo:0.106 AS builderCOPY --chown=hugo:hugo . /home/hugo/appRUN hugoFROM nginx:1.22-alpineCOPY --from=builder /home/hugo/app/public/ /usr/share/nginx/html$ docker build -t myblog:nginx .$ docker image ls --format "{{.Repository}}\t{{.Tag}}\t{{.Size}}" | grep myblogmyblog nginx 29MB构建进去而最终交付镜像的大小为 29MB 。 Easyhttpd On Alpine起初,我发现了一个用GoLang编写的轻量级web服务器 - easyhttpd,于是我Fork了该我的项目,编写了一个Dockerfile来构建该web服务器的镜像,具体可查看该文件内容。 镜像我已公布在mengzyou/easyhttpd。 $ docker image ls --format "{{.Repository}}\t{{.Tag}}\t{{.Size}}" | grep easyhttpdmengzyou/easyhttpd v0.0.1 13.7MB镜像大小为 13.7MB,比 nginx:alpine 的镜像小了十几MB。应用该镜像构建来构建我的博客站点 ...

November 20, 2022 · 1 min · jiezi

关于devops:DevOps|乱谈开源社区开源项目与企业内部开源

之前《从特拉斯辞职风波到研发效力中的荒唐事》中对于企业内源的内容在研发效力群内引起了大家的热烈探讨。有的小伙伴不批准,有的小伙伴十分不批准,我感觉这都是十分失常的反馈,话不说不透,理不辩不明。这篇文章就是那篇文章的后续,本文次要探讨开源社区、开源我的项目以及企业内源。 企业外部开源 外部开源(Inner Source)简称内源,指把开发开源软件中学到的经验教训利用到公司或组织外部开发软件的实际。公司和组织能够在外部开源的同时开发专有软件。 开源社区概念开源社区又称凋谢源代码社区, 个别由领有独特兴趣爱好的人所组成 ,依据相应的开源软件许可证协定颁布软件源代码的网络平台,同时也为网络成员提供一个自在学习交换的空间。因为开放源码软件次要被分布在全世界的编程者所开发,开源社区就成了他们沟通交流的必要路径,因而开源社区在推动开源软件倒退的过程中起着微小的作用。 开源社区的特点1)独特兴趣爱好你对这个货色感兴趣就能够参加进去,小到更新文档,答复用户问题,大到奉献代码、优化架构、退出方向探讨。只有你有能力且失去了他人的认可,那么社区就是欢送的。违心退出就退出,感觉不适合了就退出。你不对任何一个人有任务,任何一个人也没有理由束缚你。 2)开放式交换空间基于PR的代码合作,基于 wiki 的文档合作,基于slack/telegram 或者邮件组的探讨沟通。大家「大部分」的工作都是通明的。 开源我的项目所有的物料、制品每个人都能够拜访。正式公布的版本还是会受到外围团队的审查、验证、把关等。 当然某些开源我的项目也有核心成员,他们的一些讨论会限度在肯定范畴。大体来看,这还是一个十分开放式的交换空间。 3)开放式合作:平等、自组织、精英领导因为大家是基于兴趣爱好而来,那么来去自由。想关注 Watch/Star 我的项目即可;想奉献内容 Fork/PR 过去,会有人查阅你的 PR;本人曾经很相熟我的项目了,在 Issue 讨论区帮忙答复用户问题也可。总之想对一个我的项目进行奉献,是没人限度你的。 尽管退出的门槛很低,然而开源合作是有「运行规定」的。每个我的项目都有一些核心成员,这些成员次要是把控我的项目后退的方向,推动我的项目后退,承受其他人的 PR,同时对我的项目投入更多的精力产出更多的内容。 开源社区是一个以独特兴趣爱好为根底的、涣散的组织。 企业的概念古代的企业是依法设立的,以营利为目标,使用各种生产因素(土地、劳动力、资本和技术等),向市场提供商品或服务,履行自主经营、自负盈亏、独立核算的法人或其余社会经济组织。从实质上,企业是一个以盈利为目标的经济组织。 如果肯定非要说企业都由什么兴趣爱好的人组成,那就是都领有「独特赚钱的喜好」。 企业的特点企业是一个由组织机构、规章制度组成的的社会组织,需与员工签订劳动合同,而造成的一种开放式的社会组织。企业给员工各种福利待遇,员工依照公司要求尽职尽责,不存在自组织的因素。 企业不须要依附血统、亲缘等其余关系,更不依赖于兴趣爱好;公司里也会有各种公司组织的社团,提供一些经费场地等,但基本目标还是服务好员工,让员工有更好的产出。 企业作为一种社会组织,他的目标就是盈利,一直进步经济效益。如果说做开源社区能够给公司带来经济效益,那么公司也能够抉择做;但做开源社区只是一种伎俩,而不是目标。 企业并不是一个齐全开放式的空间,通常来说员工的薪资待遇股票期权等在公司都是禁止公开探讨的。公司的倒退策略等也是高层领导确定后把论断周知大家,至于决策等过程、用到的数据、利弊的思考等都会受限于特定的人群,个别也不会在公开场合探讨。 已经有一家公司,企业内网有一个齐全匿名的 BBS。匿名 BBS 的出发点是好的,给大家一个自在探讨的空间。我感觉这是一个十分好的「探讨本质内容」的中央。只有你把事件的原委说明确,基本上都能失去妥善解决。公司的人力、行政、食堂、财务、法务等都违心在下面答复大家的问题。然而起初局部同学开始一直在下面质疑公司的业务指标、公司的经营策略,公司的打法经营伎俩等。。。。这曾经超出了「理论问题」的档次,甚至曾经到了「价值观」。最初倒退的后果就是勾销了匿名,从此 BBS一潭死水,而很多本来能在内网解决的问题,却都变成了脉脉上的各种牢骚。企业是一个自上而下的组织架构,有很多的层级,上对下有考核、治理、领导的权力;这一点和开源社区区别很大。尽管开源社区也有精英式领导,但顶多承受或者回绝你的 PR,谈不上治理,更没有考核。 开源社区+企业企业和开源社区也能够联合。比方 Redhat。 Redhat 已经是一个纳斯达克上市公司(2018年被 IBM收买),它是一家开源解决方案供应商,为诸多重要IT技术如操作系统、存储、中间件、虚拟化和云计算提供要害工作的软件与服务。Redhat 是很多重大开源我的项目的次要贡献者。雇佣专职的员工为开源社区奉献代码,而后将开源社区我的项目产品化,达到盈利。 企业外部开源的目标是啥?企业为啥要做外部开源(inner source)? 从内源的维基百科上,咱们能够看到次要动机就是 1)想在外部建设相似开源的文化 2)在企业外部开发专有软件。 1)独特兴趣爱好:如果某些人对我的项目感兴趣能够被迫去学习、去退出2)开放式交换空间:某些我的项目的文档、代码、制品都凋谢3)开放式合作:平等、自组织、精英领导做到以上三点不难。如果仅仅是把repo 权限关上、文档放开、凋谢探讨,那前面怎么让我的项目停顿上来呢?这是咱们要思考的问题。 企业外部我的项目和开源社区我的项目异同企业外部的我的项目都有团队归属的属性。开源社区的我的项目尽管也有核心成员,然而你齐全能够 fork 一个本人的仓库,本人保护,不必在乎核心成员和原我的项目。 企业外部我的项目做不好,有追责的机制,投诉的机制:开源社区的我的项目没有这个机制,你感觉我的项目做得不好你来奉献。 企业外部的我的项目都有明确的工夫节点,都有交付日期的布局。到什么工夫点交付什么制品都是有分明定义;尽管开源社区有的我的项目也有日期布局,但也只是布局,延期交付,大家也感觉没啥,毕竟大多数人是白吃人家饭,还要厌弃人家饭晚么? 企业外部我的项目都有品质要求,这个团队做这个我的项目,那么就要对这个我的项目品质负责,出了问题,你要修复;尽管优良的开源社区我的项目呈现了问题,尤其是重大问题,负责任的团队也会及时修复,但这不是任务,更多还是一种自我谋求。大多数我的项目都是「你行你上,不行别BB」 企业外部我的项目都有产品方向,策略、门路、指标打算,你能够「谏言」,提出好的倡议,然而最终还是负责团队「决策」。 所以开源我的项目是一个成员人数不定、自组织、精英式队员领导的没有盈亏核算的涣散我的项目。对于何时能满足用户需要具备很强的不确定性。而企业外部我的项目是团队组织架构清晰,有明确负责人负责的在肯定工夫内达到某种目标的自负盈亏的我的项目。对于企业外部我的项目,工夫、范畴、品质、老本都有明确的要求。 企业内源怎么能力做起来?那我就想在企业外部搞企业内源,我怎样才能搞起来呢?什么样的我的项目适宜呢? 曾经具备肯定性能,仍需增加小需要的维护性我的项目对时限没有严格要求的小我的项目公司气氛是宽松的,员工有“闲”公司的代码评审做得很好撑持的基础设施绝对欠缺,不须要更多其它角色染指(比方设计师、QA等)通过下面就能够看到只有人闲,且需要没有deadline,这样的内源我的项目兴许能力跑起来。 国内企业内源现状线下和一些华为腾讯百度的小伙伴粗疏理解了下企业内源的状况,总的来说,企业内源是能够做的一件事,然而成果和前景并不像网上说的那么光鲜亮丽。花了很大力量去搞,成果其实个别。对于一个大公司, 如果大家感觉本人很闲 ,想竖起大旗做个专项,弄个企业内源,当成个事向上汇报还是能够的,但别太当回事。都冷静下来想一想,华为腾讯百度这种本身工作都卷到10点多回不了家的公司,怎么可能很闲,怎么可能靠「独特趣味」去搞企业内源?除非做企业内源也是我工作的一部分,是我的「职责范畴」。那和理论的我的项目制本质区别又在哪里? 文章总结开源我的项目和企业外部我的项目差异很大,形类似义不同。对于「盈利」有很高要求的企业,我的项目的目的性十分强,对时限有明确的要求。我的项目的工夫、范畴、品质、老本都会纳入考量的因素,通过在不同因素间进行掂量,做出最佳的决策。如果企业内源不能在时限上给出明确的工夫点,对范畴、品质、老本也不能明确进去,大部分企业外部我的项目都不可能以这种模式开展。 以上探讨的范畴限度在中小企业(研发小于3000人),有专职团队负责根底工具,中台工程类建设的状况。 更多内容 从特拉斯辞职风波到研发效力中的荒唐事内源的维基百科Tim O'Reilly企业外部开源 ...

November 8, 2022 · 1 min · jiezi

关于devops:10-New-DevOps-Tools-to-Watch-in-2023

With less than two months left in 2022, today, I’d like to look at some new (relatively) DevOps tools we might want to follow in the next year because they might boost engineering productivity to the next level. Author’s note: it’s worth noting that not all of them are “brand new” tools released recently; most of them are probably tried out by the CNCF end-user community. It’s recommended to look at these tools when you have a specific need for the technology in your projects.Without further adieu, let’s get started. ...

November 8, 2022 · 11 min · jiezi

关于devops:六大招式修炼极狐GitLab-CICD-快-字诀

本文来自:李发富 极狐(GitLab) 高级技术支持工程师家喻户晓,CI/CD 能够让咱们更快、更高质量、更简略的交付软件。而事实中,你是否常常面临以下难点,导致 CI/CD 并没有真正施展其劣势: 从网络装置我的项目依赖耗时长?前后端我的项目未分离,导致编译、部署及测试效率低?随着我的项目增多,多任务 Pipeline 运行慢?不必要 Job 运行占用了资源和工夫? 针对以上问题,我总结了六大招式,心愿帮忙大家在应用极狐GitLab 时候晋升 CI/CD 效率,供参考。 应用 cache在运行我的项目编译时,可能会装置我的项目依赖,如果每次都从网络装置,会节约很多工夫。这时候能够应用 cache 性能提供缓存,缩小依赖安装时间。 【前提】runner 开启 cache 性能:Advanced configuration | GitLab python cache示例: image: python:3.9.7stages:  - testvariables:  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"  cache:  paths:    - .cache/pip/  # 已我的项目 id 辨别 cache,如果不辨别,就是全局 cache  key: $CI_PROJECT_IDjob1:  stage: test  script:    - pip install ansible==2.9.2or image: python:3.9.7stages:  - testcache:  paths:    - pip-cache  # 已我的项目 id 辨别 cache,如果不辨别,就是全局 cache  key: $CI_PROJECT_IDbefore_script:  - export PIP_CACHE_DIR="pip-cache"  - mkdir -p pip-cachejob1:  stage: test  script:    - pip install ansible==2.9.2nodejs cache示例: variables:  NPM_CONFIG_CACHE: npm_cache  NPM_CONFIG_REGISTRY: https://registry.npm.taobao.orgdefault:  cache:    paths:      - ${NPM_CONFIG_CACHE}build:  stage: build  image: node:14-alpine  script:    - node -v    - npm -v    - npm ci    - npm run build  artifacts:    name: "build-package"    paths:      - dist    expire_in: 1 dayjave maven cachebuild:  image: maven:3.8.5-jdk-11  stage: build  variables:    MAVEN_CLI_OPTS: "-s .m2/settings.xml --batch-mode"    MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"  cache:    paths:      - .m2/repository/      - target/    key: $CI_PROJECT_ID  script:    - mvn package    - ls -l target/*应用 needs 扭转多阶段执行程序默认状况下,同一阶段作业并行运行,不同阶段按程序执行,存在排队等待时间,以致编译、测试工夫被拉长。 咱们能够应用 needs 参数扭转多阶段执行程序:Pipeline 定义阶段 Stages,如果全局未定 Stages,则按程序运行 Build,Test,Deplo。Job 如果未设置 Stage,默认是 Test 阶段。 示例: stages:  - build  - test  - deploybuild fontend:  stage: build  script:    - echo 'build fontend job'build backend:  stage: build  script:    - echo 'build backend job'test fontend:  stage: test  script:    - echo 'test fontend job'  needs: ["build fontend"]test backend:  stage: test  script:    - echo 'test backend job'  needs: ["build backend"]    deploy fontend:  stage: deploy  script:    - echo 'deploy fontend job'  needs: ["test fontend"]deploy backend:  stage: deploy  script:    - echo 'deploy backend job'  needs: ["test backend"]应用 needs 参数后:对于前端工作,build fontend 实现后会立刻执行下一个阶段的 test fontend,不论 build backend 是否实现。后端的 build backend 工作一样相似。 Web 界面中还能够查看 needs 依赖关系: 应用 rules 缩小不必要 Job 运行很多人会把前后端一起打包和部署,但其实只有前端代码有变动,针对后端的 Job 测试是多余的。因而,能够应用 rules 规定跳过某些不必要 Job。 ...

November 7, 2022 · 2 min · jiezi

关于devops:平均110万个漏洞被积压企业漏洞管理状况堪忧

在软件平安的世界中,企业在软件开发生命周期中都面临着破绽带来的微小挑战。开发人员每天都须要确保交付没有破绽的代码,因而他们须要破费大量的工夫来解决首要解决的破绽问题以确保企业软件平安。然而确保产品没有破绽缺点的需要扼杀了翻新的步调,提早软件产品的上市工夫并导致支出和工夫上的巨大损失。 业内权威征询钻研机构 Ponemon Institute 对634位 IT 和平安领导者进行采访,就企业 DevSecOps 在治理破绽和攻击面方面进行钻研和考察,并公布企业 DevSecOps 破绽治理状态报告。该报告说明了企业破绽治理的一系列现状以及所面临的挑战。 破绽积压Ponemon 示意企业在治理破绽时的另一项微小挑战就是要解决大量积压的破绽。依据报告结果显示,在过来的12个月里,均匀有110万个破绽被积压,然而其中不到一半(46%)失去修复。 尽管企业领有大量的破绽和扫描工具,不论是网络还是应用程序,再到云端及挪动端,涵盖技术基础设施的各个方面,但 Ponemon 报告钻研发现,43%的受访者认为这些工具和办法未能无效地起到作用,还有47%的受访者示意,因为他们无奈确定须要修复的破绽相应的优先级因而导致破绽积压未被修复。 随着企业积压的破绽数量逐步减少,打消这些破绽积压往往给其软件应用程序开发方面的资金和生产力造成损失。考察发现,77% 的受访者示意,检测、优先排序和修复生产中的一个破绽每个步骤须要超过 21 分钟,这样意味着生产端的一个破绽须要破费一个多小时的工夫。 在开发方面,破绽治理变得更加有挑战性。据报告结果显示,确定优先级和修复工夫也很长,有82% 的受访者示意修复开发中的一个破绽须要超过 21 分钟,85% 的受访者示意确定开发中的一个破绽的优先级须要超过 16 分钟。 当被问及在环境中检测到重大或高风险破绽均匀须要多长时间能力修复时,14%的受访者示意须要6周,须要7周的占16%,须要8周的占15%,还有13%的受访者示意须要9周来实现修复!修复破绽的工夫越长,破绽被利用的危险就越大,企业攻击面也会随之减少。 Seal 软件供应链防火墙 能够为用户匹配破绽修复的优先级,并主动提供修复倡议,大大节俭破绽修复工夫,极大水平升高企业被攻打的危险。 漫长的破绽检测和修复过程导致了破绽的积压。报告结果显示,有66%的受访者示意其所在的企业积压的破绽至多有100,000个,其中54%的人示意他们可能修补不到一半的积压破绽。手动检测、确定优先级再到修复破绽,这意味着企业团队每年须要破费数千小时进行破绽积压治理。 破绽治理能力有余在受访者被问到以1到10的等级来评估其所在的企业在优先解决要害破绽的有效性,只有29%的人示意他们所在的企业在此方面十分无效。同样1到10的范畴评估破绽修补的及时性时,只有30%的受访者示意其所在企业可能无效且及时地修补破绽。 这也阐明企业并未能领有足够的能力来治理破绽。 而在尝试解决破绽积压问题时,有几个因素正在给企业带来挑战。即无奈确定须要修复的优先级,没有足够的对于可能利用破绽的危险的信息,和不足无效的工具和资源。如之前所述,许多企业正在破费大量工夫来解决大量破绽积压问题,而平安团队无奈确定破绽的优先级以疾速解决最要害的破绽。超过一半的受访者 (53%) 示意其所在的企业只关注那些形成最大危险的破绽,而不是专一于修复所有破绽。然而,还有靠近一半的受访者示意,因为不确定哪些破绽带来的危险和危害最大,他们所在的企业修复了所有破绽。 因而 Ponemon 表明,企业须要正确的工具和策略来自动化破绽的检测、优先级和修复过程。否则他们无奈理论治理破绽积压。 自动化和 DevSecOps 是要害当今破绽治理的毛病之一是无奈确定破绽的优先级,而胜利确定优先级的要害是使流程自动化。平安团队须要主动确定优先级,以使他们的补救工作更加及时和高效。自动化此过程能够显着缩小确定哪些破绽是最大危险所需的工夫。除了自动化之外,领有成熟的 DevSecOps 程序应该是破绽管理策略的重要组成部分。企业必须采取必要的步骤来推动他们的 DevSecOps 打算。 应用自动化进行破绽治理的企业正在看到成绩。例如,超过一半的受访者示意他们的企业应用自动化来修复破绽,其中大多数人示意此举曾经产生了显着的收益。当被问及自动化如何影响修复破绽所需的工夫时,43% 的人示意响应工夫显著缩短。当问及企业将哪些步骤自动化,后果是破绽修复(59%),破绽优先级排序(47%)以及破绽报告(41%)。 此外,企业也该当承受并施行“平安左移”,并将 DevSecOps 放在首位,因为 DevSecOps 框架从构建过程开始就为软件生命周期的所有阶段增加了自动化平安测试和协调,而不是为最终的软件审查阶段保留破绽测试环节。 许多企业都在致力充分利用 DevSecOps,尽管他们在优化模型应用方面面临阻碍,包含不足正确的平安工具、不足工作流集成、一直减少的破绽积压以及应用程序安全漏洞的增长,但这仍是确保软件开发平安的要害组成部分。DevSecOps 能够通过辨认在企业环境中不可利用的破绽来缩小高达 85% 的破绽积压以及修补工作。依据考察结果显示,45%的受访者示意采纳 DevSecOps 的次要起因是缩小修复破绽所需的工夫,还有33%的人示意 DevSecOps 可能帮忙确定危险的优先级程序和补救措施。

November 3, 2022 · 1 min · jiezi

关于devops:一文读懂-DevSecOps工作原理优势和实现

因为 DevOps 办法的宽泛采纳以及由此产生的疾速产品交付和部署,许多部门已采纳更麻利的办法来开发生命周期。在满足市场速度和规模要求的同时,设计平安的软件始终是古代 IT 公司独特面临的问题。后果,超过 52% 的组织因为放心上市速度落后而放弃了安全性。 因为传统技术下的安全漏洞,生产版本也呈现了提早。因而,一些企业曾经采纳 DevSecOps 办法来解决这个平安方面的问题。然而,当公司从 DevOps 转向 DevSecOps 时,他们常常面临一系列规范阻碍。 或者对于 DevSecOps 这个词大家并不生疏,那么对于 DevSecOps 的理解又有多少呢?浏览本文,带你全面了解 DevSecOps 是什么。 什么是 DevSecOps?DevSecOps 是形容开发、平安和运维集成的术语。它是一种文化、自动化和平台设计策略,强调平安是整个 IT 生命周期中的独特责任。DevSecOps 从一开始就思考到安全性来创立应用程序和基础设施的做法,同时波及自动化安全检查,免得减慢以后的 DevOps 流程。为了满足平安指标,平安团队为继续集成平安抉择和装备适合、正确的工具来满足必要的爱护。 DevSecOps 的工作原理DevSecOps 是开发组织解决平安问题的必然和天然倒退。在过来,企业确保软件平安的形式往往是在开发周期完结时由平安团队为软件增加爱护,而后再通过 QA 团队进行测试。这在不那么频繁地提供软件降级的时候的确是可行的。 然而随着软件工程师转向麻利和 DevOps 以将软件开发周期缩短数周甚至数天,传统的“附加”平安办法曾经无奈持续无效保障软件安全性。而 DevSecOps 可能将应用程序和基础架构安全性无缝地联合到麻利和 DevOps 流程和工具中。一旦发现安全漏洞,就会立刻进行解决和修复,这样就可能以更容易、更快、更便宜的形式在软件投入生产之前缓解或打消平安危险。 此外,不同于 DevOps,DevSecOps 让应用程序和基础设施的安全性成为开发、平安和 IT 运维团队的独特责任,通过在不减慢软件开发过程的状况下自动化安全软件交付。 DecSecOps 的劣势DevOps 将业务要害应用程序在性能、速度、性能和规模方面晋升到了一个全新的程度。然而因为不足合规性和牢靠的安全性,这些应用程序有时会滞后。而将 DevSecOps 集成到软件开发生命周期中就等于把开发、平安和经营置于一个对立的框架之下。借助 DevSecOps,每个开发人员和运维人员都将在开发和部署要害业务应用程序的每个阶段优先思考安全性。 DevSecOps 的劣势在于: 升高合规老本更快地部署应用程序进步软件交付率从软件开发的最开始就进行安全检查、继续监控和主动部署查看从利用程序开发的晚期阶段进步可视性和透明度在蒙受平安攻打的状况下可能更快地复原通过启用进一步平安自动化来进步整体安全性DevSecOps 的施行施行 DevSecOps 可能让企业保持高速、敏捷地开发和翻新,同时满足合规要求且永远当先攻击者一步。从 DevOps 切换到 DevSecOps 看起来简单且不易执行,企业能够参考以下六点: 代码剖析 - 以小规模、高频率的版本交付代码,以便更轻松高效地查看破绽,同时将代码剖析嵌入 QA 流程中。变更治理 - 容许并激励开发人员随时提出重要工作平安更改倡议并尽可能在24小时内批准更改,让变更治理流程变得更加高效。合规监控 - 在开始编写代码或进行更改时收集合规性证据,以便让开发继续处于合规状态。威逼钻研 - 针对应用新交付代码对企业所做出的更改而产生的威逼或破绽进行查找、考察、钻研并且进行修改。破绽治理及评估 - 在公布代码并实现破绽查看后,定期进行扫描并进行代码审查和浸透测试。平安培训 - 激励技术人员加入行业会议或平安认证会议,并定期为他们提供平安开发的相干培训。 ...

October 26, 2022 · 1 min · jiezi

关于devops:Pipeline流水线设计的最佳实践

谈到到DevOps,继续交付流水线是绕不开的一个话题,绝对于其余实际,通过流水线来实现疾速高质量的交付价值是绝对能疾速奏效的,特地对于开发测试人员,可能取得实实在在的收益。很多文章介绍流水线,不论是jenkins,gitlab-ci, 流水线,还是drone, github action 流水线, 文章都很多,然而不论什么工具,流水线设计的思路是统一的。于此同时,在实际过程中,发现大家对流水像有些误区,不是一大堆流水线,就是一个流水线调一个超级简单的脚本,各种硬编码和环境依赖,所以心愿通过这篇文章可能给大家分享本人对于Pipeline流水线的设计心得体会。 概念继续集成 (Continuous Integration,CI)继续集成(CI)是在源代码变更后自动检测、拉取、构建和(在大多数状况下)进行单元测试的过程对我的项目而言,继续集成(CI)的指标是确保开发人员新提交的变更是好的,不会产生break build; 并且最终的骨干分支始终处于可公布的状态,对于开发人员而言,要求他们必须频繁地向骨干提交代码,相应也能够即时失去问题的反馈。实时获取到相干谬误的信息,以便疾速地定位与解决问题显然这个过程能够大大地进步开发人员以及整个IT团队的工作效率,防止陷入好几天得不到好的“部署产出”,影响后续的测试和交付。 继续交付 (Continuous Delivery,CD)继续交付在继续集成的根底上,将集成后的代码部署到更贴近实在运行环境的「预公布环境」(production-like environments)中。交付给品质团队或者用户,以供评审。如果评审通过,代码就进入生产阶段 继续交付并不是指软件每一个改变都要尽快部署到产品环境中,它指的是任何的代码批改都能够在任何时候实时部署。强调: 1、手动部署 2、有部署的能力,但不肯定部署 继续部署 (Continuous Deployment, CD)代码通过评审之后,主动部署到生产环境中。继续部署是继续交付的最高阶段。 强调 1、继续部署是主动的 2、继续部署是继续交付的最高阶段 3、继续交付示意的是一种能力,继续部署则是一种形式 流水线的编排设计参考: https://docs.gitlab.com/ee/ci/pipelines/pipeline_architectures.html这里十分举荐以版本控制系统为源的构建流水线设计,从每一位开发人员提交代码即可对以后提交代码进行查看编译构建,尽快将谬误反馈给每位提交人员。对于DevOps流水线,次要是由各类工作串联起来,而对于工作自身又分为两张类型,一种是自动化工作,一种是人工执行工作。具体如下: 自动化工作:包含了代码动态查看,构建,打包,部署,单元测试,环境迁徙,自定义脚本运行等。人工工作:人工工作次要包含了查看审核,打标签基线,组件包制作等相似工作。而通常咱们看到的流水线根本都由上述两类工作组合编排而成,一个流水线能够是齐全自动化执行,也能够两头退出了人工干预节点,在人工干预解决后再持续朝下执行。比方流水线中到了测试部署实现后,能够到测试环境人工验证环节,只有人工验证通过再流转到迁徙公布到生产环境动作工作。DevOps流水线实际上和咱们原来常常谈到的继续集成最佳实际是相当相似的,较大的一个差别点就在于引入了容器化技术来实现自动化部署和利用托管。至于在DevOps实际中,是否必须马上将我的项目切换到微服务架构框架模式,反而不是必须得。 在整个DevOps流水线中,咱们实际上强调个一个关键点在于“一套Docker镜像文件+多套环境配置+多套构建版本标签”做法。以确保咱们最终构建和测试通过的版本就是咱们部署到生产环境的版本。构建操作只有一次,而前面到测试环境,到UAT环境,到生产环境,都属于是镜像的环境迁徙和部署。而不波及到须要再次从新打包的问题。这个是继续集成,也是DevOps的根本要求。 流水线工作的标准化/原子化明天谈DevOps流水线编排,次要是对流水线编排自身的灵活性进一步思考。 构建操作:构建咱们通常采纳Maven进行自动化构建,构建实现输入一个或多个Jar包或War包。留神惯例形式下构建完执行进行部署操作,部署操作个别就是将构建的后果拷贝到咱们的测试环境服务器,同时对初始化脚本进行启动等。而在DevOps下,该操作会变成两个操作,即一个打包,一个部署。打包是将构建实现的内容制作为镜像,部署是将镜像部署到具体的资源池和指定集群。 打包镜像操作:实际上即基于构建实现的部署包来生成镜像。该操作个别首先基于一个根底镜像文件根底上进行,在根底镜像文件上拷贝和写入具体的部署包文件,同时在启动相应的初始化脚本。那么首先要思考构建操作和打包操作如何松耦合开,打包操作简略来就是就是一个镜像制作,须要的是构建操作产生的输入。咱们能够对其输入和须要拷贝的内容在构建的时候进行约定。而打包工作则是一个标准化的镜像制作工作,咱们须要思考的仅仅是基于1)基于哪个根底镜像 2)中间件容器默认目录设置 3)初始化启动命令。即在理论的打包工作设计的时候,咱们不会指定具体的部署包和部署文件,这个齐全由编排的时候由上游输出。 部署操作:部署操作相当更加简略,重点就是将镜像部署到哪个资源池,哪个集群节点,初始化的节点配置等。具体部署哪个镜像不要指定,而是由上游工作节点输出。工作节点间松耦合设计的意义这种松耦合设计才可能使流水线编排更加灵便。比方咱们在进行了构建打包后,咱们心愿同时讲打包内容部署到开发环境和测试环境。那么则是打包动作实现后须要对接两个利用部署工作。这两个部署工作都依靠下面的打包后果进行自动化部署,能够并行进行。对于测试环境部署实现后,咱们须要进行测试人员手工验证测试,如果测试通过,咱们打标签后心愿可能间接公布到UAT环境。而这种操作咱们也心愿在一个流水线来设计和实现。这样咱们更加容易在继续集成看板上看到整个版本构建和迁徙的残缺过程。如果这是在一个大流水线外面,那么对于UAT环境部署工作就须要始终去追溯流水线上的最近的一个打包工作节点,同时取该工作节点产生的输入来进行相应的环境部署操作。在谈DevOps的时候,一个重点就是和QA/QC的协同,因而在流水线编排的时候肯定要思考各类测试节点,包含动态代码查看,自动化的单元测试,人工的测试验证。同时最好基于继续集成实际,可能将测试过程和整个自动化构建过程紧密结合起来。简略来说,测试人员发现build1.0.0001版本4个bug并提交,那么在下次自动化构建实现并单元测试通过后,测试人员可能很分明的看到哪些Bug曾经批改并能够在新构建的版本进行验证。只有这样才可能造成闭环,整个流水线作业才可能更好的施展协同作用。 流水线中蕴含的工程实际流水线除了工作步骤的编排,更重要的外围是最佳工程实际的体现。过来传统的思维,自动化就是写个shell/python脚本批量执行,在DevOps/微服务时代,这一招太out了,每种工程实际的背地都有须要解决的问题,通过在流水线设计中注入最佳的工程实际,能够让流水线的价值最大化,也让流水线更高级不是嘛。 版本控制 - 解决的问题:需要和代码的关系,版本变动的跟踪最优的分支策略 - 解决的问题:版本公布和团队合作,某些状况会和环境有关系代码动态扫描 - 解决的问题: 开发标准和平安的问题80%以上的单元测试覆盖率 - 解决的问题:代码性能品质的问题,让测试左移破绽(Vulnerability)扫描 - 解决的问题:部署环境/产品安全的问题开源工具扫描 - 解决的问题:解决供应链平安问题,别忘了log4j制品(Artifact)版本控制 - 解决的问题:制品的版本控制,制品的升级,某些状况下环境的回滚环境主动创立 - 解决的问题:解决的是构建/部署环境一致性的问题,开发测的好好的,测试一验证怎么不行啊,容器化/云原生让这个问题更好的解决不可变服务器(Immutable Server ) - 解决的问题: 可能不好了解,打个比方如果如果你的服务器挂了,或者某次配置更改了服务就起不来了,应用不可变基础设施的次要益处是部署的简略性、可靠性和一致性,服务器能够随时替换上线集成测试性能测试每次提交都触发:构建、部署和自动化测试 - 解决的问题:疾速失败,防止上游工夫的节约自动化变更申请 - 解决问题:某些场景下通过状态变更触发某些动作零停机公布 - 解决的问题:滚动/蓝绿/灰度公布等,用户无感知性能开关 - 解决的问题: 骨干开发中,如果某个性能没凋谢完,就通过on/off某个个性来让稳固的性能上线;还有一个场景,比方某些面对消费者的广告网站,想看看本人某个性能客户是否细化,通过性能开关看看市场反馈,个别和A/B测试配合 ...

October 25, 2022 · 4 min · jiezi

关于devops:4000字深度总结Pipeline五大性能实践招招制敌

本文来自:毛超 极狐(GitLab) 研发工程师太长不读版 你将看到「Pipeline 运行很慢」的问题剖析和解决思路,并理解极狐GitLab CI/CD 解决该问题的最佳实际。 - END Hold on, hold on! 精彩才刚开始,且听我缓缓道来~ 一千个人的心中,就有一千种 DevOps。从2009年 DevOps 概念的衰亡到明天,衍生出各种各样的工具、标准、流程、准则,足以让人目迷五色。 作为软件工程师,我习惯探索一种技术或者概念的外围逻辑,在我看来,DevOps 的外围逻辑就是通过继续集成和继续交付扭转团队交付软件的形式,所以继续集成和继续交付就天然成为 DevOps 的两大外围能力,在各种 DevOps 的书籍中也有着重要的篇幅。 极狐GitLab 作为一体化 DevOps 平台,提供了丰盛且弱小的 CI/CD 性能,然而依据我在极狐GitLab 用户微信群中察看到的状况看,仍然有研发团队在实际 CI/CD 过程中,呈现 「现实很现实,事实很事实」的困境,碰到各种各样的问题。 明天我就来分享下极狐GitLab CI/CD解决典型问题的最佳实际,心愿能抛砖引玉,给更多研发团队提供帮忙。(下文中的微信群聊都曾经过批改,请勿对号入座) 这些问题你遇上过吗? 从下面的群聊中能够看出,大家的 Pipeline 运行的都不快,甚至能够说很慢。如果你也有上述相似的问题,首先要恭喜你,因为只有保持实际 CI/CD 的团队,才会碰到这种「苦涩的懊恼」。Pipeline 在日常开发中表演重要角色,一旦呈现性能问题,会极大地影响团队效率,必须加以器重。我置信有些简略的解决思路,例如「性能不够,机器来凑」,惋惜这种有钱任性的形式不肯定可能解决问题。 作为软件工程师,碰到性能问题,正确的做法应该是查看运行 Log 确定性能瓶颈,剖析具体性能问题,最初再进行相应的优化。所以,首先要做的就是查看 Pipeline 的运行 Log,明确每一个 Job 的运行状况,能力定位出某些有性能问题的 Job 并给出解决方案。上面我将分享解决 Pipeline 性能问题的一些最佳实际,供参考~ 最佳实际分享实际一:优化下载内部依赖一般来说,Pipeline 在运行过程中都会从内部获取依赖,比方拉取我的项目的依赖包,Java 用 Maven/Gradle,Ruby 用 bundler,NodeJS 用 npm/yarn 等,这时咱们就能够在 .gitlab-ci.yml 文件(Pipeline 的定义文件)中应用 cache 关键字,将内部依赖包缓存起来,这样就防止了每次反复下载的动作,能够节俭不少工夫。cache 的应用也很简略,相似上面的代码: cache-job: script: - echo "This job creates a cache." cache: key: third_party_dependency paths: - vendor/ruby - node_modules在下面的 Job 中,cache-job 缓存了 cache:paths 中指定目录 vendor/ruby 和 node_modules 外面的内部依赖包,cache:key 指定了缓存的惟一标识。这样在 cache-job 运行完结后,会将 cache:paths 中的所有文件打包上传到极狐GitLab 配置的 cache 地址中,当 Pipeline 再次运行时,会主动下载 cache 中的文件,并存放在 cache:paths ,这样就能够防止反复下载。极狐GitLab 有更多的 cache 用法,具体应用办法请查看文档 .gitlab-ci.yml 参考。 ...

October 24, 2022 · 2 min · jiezi

关于devops:DevOps-中遇到的不靠谱荒唐事

今儿一早就听到,英国第78任首相伊丽莎白·特拉斯发表辞职。特拉斯上任后任命她的「密友克沃滕」出任财政部长推出「迷你估算」后果引来英国金融大震荡,英镑对美元汇率跌幅达3%,股市和英国国债均大幅下挫。最初架不住投资者、保守党和民心,辞去英国保守党党首职务,主动卸任英国首相职务,任职45天,也是英国历史上任期最短的首相。 迷你估算这事干的真不靠谱,一发进去股市、汇市、国债齐跌。具体起因大家能够自行搜寻,总之这就是不靠谱的人不业余的人才能捅出来的大窟窿,凡是有点花生米也不至于如此。我做研发效力这么多年,也见过一件只有不靠谱的研发效力团队能力干出的事。 这件事就是把全公司「90%」的代码仓库设置成全 internal 。什么意思呢?只有你是 gitlab 的用户并且登录,那么公司除了少部分被设置成 private 的代码仓库,其它 90% 以上的仓库你都可读(能够克隆到本地)。当很多公司都在梳理仓库权限,倡议把权限设置成 private 的时候,竟然有人推动把公司的绝大部分仓库凋谢进来。我理解了一下,这样做的目标是我的项目公司外部开源。过后我心田的想法是「擦....老板又被不靠谱的人给忽悠了」。

October 23, 2022 · 1 min · jiezi

关于devops:高效能敏捷交付DevOps团队特性团队FeatureTeam-Scrum

个性团队和Scrum,这两个定义在我之前的文章中都具体介绍了。这两个组织模式或者说治理实际,我都用过所以有些时候特地有感触。书本上纯正的模式很容易了解,然而具体工作中使用这是十分考验团队和人的,尤其是波及到考核和汇报关系就会很简单。本篇文章次要来唠唠我理论应用时的感触和了解。 个性团队定义个性团队是一个长期稳固、跨职能跨组件、继续端到端交付用户价值的团队。Scrum 定义Scrum是一个用于开发和保护简单产品的框架,是一个增量的、迭代的开发过程,目标是让开发人员像打橄榄球一样迅猛并充斥激情,通过团队单干,进步工作效率。通过团队间的无效交互,为企业发明价值。不确定性的世界简略地总结下Scrum的单干模式是:PO负责打算、定义性能、验收产出,Scrum Master 负责流程,Team 负责实现。如果真这样去用,会不会有啥问题?对于日常的工作这样安顿没有问题,然而对于非「循序渐进」的事如何解决呢?放到产品代办列表中?PO去跟进?还是Scrum Master 去跟进?器重团队绩效而不是集体绩效,所有人都同一个系数还是各不相同?同一个系数,摸鱼的无所谓,拼命的的必定受委屈。如果干多干少一个样干好干坏一个样当前有事谁还往前冲?定义是一方面,真的带团队做事件每天遇到「鸡毛蒜皮」「柴米油盐酱醋茶」的事件太多太多。咱们不是在象牙塔里,咱们要在简单的世界中前行,所以这些非「循序渐进」的事须要有人负责。这也就是个性团队提倡的要以一种「全职能」的团队去应答各种不确定。 各司其职+相互配合为了谋求效率最大化,各种分工越来越细,术业有专攻。每个人都在忙范畴划定、能力所及的事,总感觉这不是一个「Team」,而是「迎面喊声兄弟借个火」的路人。能够说这是一个涣散的,靠被迫、靠趣味来驱动的组织。 人都是有惰性的,团队压力小还能相安无事。真想做出点事件,压力一大,工作工作多,须要每个人有更多承当的时候就会呈现问题。不是说自组织么?不是说自领工作么?实质是Scrum 这种模式在人员素质高、工作压力不大,人员配置短缺,分工正当的企业还能进行的上来,比方外企。因为很多外企在国内的局部都是老本核心,通常也不会有营收指标,你好我好大家好。然而对于很多还处在生死线上的企业是否适合?我本人感觉靠趣味,靠影响力去驱动是不靠谱的。在公司里就要业余一些,职业一些。 PO,SM和Team 这三个「脑袋」驱动整个团队向前走,但有点问题就会十分内耗。能同时影响这三头「猪」的人是谁?如果是一只「鸡」还好,往往还是好几只「鸡」。这些「鸡」不在团队里,平时也不加入各种会议,只是偶然听下汇报,然而却考核团队里的「猪」。这只「鸡」不在团队里却对团队效力影响很大。 Scrum 带来了流程,还带来了「各司其职、人尽其才」, 给咱们带来一个依照标准流程做事件的组织;但三股碎麻无大用,要拧成绳能力提千斤鼎。对于公司也一样,公司的诉求也不是一个照本宣科的 scrum 团队,而是一个能拿后果、高效能的「特种部队」。 特种部队也得卷东方发达国家依附先发劣势,把握了大量先进的科学技术,即使是欧洲小国,也能够依附一两样先进技术或者不错的产品赚大钱,过上富裕、劳碌的生存。公司外面的人也不必那么拼命,循序渐进的工作,很多人喝喝咖啡闲聊几句就是一天,只有公司里有一部分在致力工作,公司就能活的很好。 而咱们不行,咱们还处在产业链的低端,还在攀登科技顶峰的途中,咱们要想爬上金字塔的顶端,光靠「循序渐进」的工作是活不下去的。所以造成了国内的公司和团队都很拼,都很「卷」。如同这一点说的有点远了,但确实在那里。 「卷」也不是满载而归。打工赚钱来的,谈钱不寒碜。「三个人干五个人的活拿四个人的钱」。如果没有更多的播种,我感觉不应该卷。实际上很多团队并不是在「卷」,而是「干耗」。加班很多却没有播种没有成绩,这种「干耗」是应该抵制的。纯干耗不如早上班。 有价值有产出的团队对于公司内的团队,底线就是要有价值有产出,在可预期的工夫内拿到预期的成果;对于集体来说,通过一段时间能有所播种(常识、技能和支出)。而这所有的所有都须要产出的保障。而要做到这些,首先要选对一个有价值的方向,其次团队在这个方向上要做出有价值的产出。 这个「有价值的方向」公司会有肯定的思考,在团队创立之初其实公司是有预期的,尽管可能很抽象、概括。因为能在一个更高的维度看到存在的问题,有解决这些问题的诉求,也有肯定的教训或者把握了一些信息,所以才要成立相应的团队来解决。大方向是有的,然而还是要靠具体团队来落实。也就是说团队成立之初是有价值的。然而团队具体有多大价值,要靠团队来证实。那么一个高效能的团队就是证实其价值的无力保障。 高效能团队一个对畛域有深刻理解,同时能率领团队拿到后果的 FTO 是要害。这样的人只有受权他,同时给予资源就能获得很好的后果。 聚起一队「跨职能、继续闭环交付用户价值」的 FT Memeber是基本。各司其职、人尽其才的同时还要有主人翁意识(ownership),能自驱,能补位。至于一些具体的流程、做法,绝对反而不那么重要。团队正向运行起来,这些问题天然会迎刃而解。 所以,我心目中的高效能团队是一个能够继续实现一个个高优先级工作的「特种部队」,团队外部职能、职责清晰,同时尽可能的闭环。这样能够顺畅沟通,高效协同,继续地端到端交付用户价值。 期待&总结成立一个高效能麻利的团队不难,难的是咱们有时候人为毁坏它。一个团队从造成到高效能有一个form-storm-norm-perform 的过程,频繁的组织变更会让团队长期处于动荡,这也就是为什么个性团队要强调「长期、稳固」。FTO 对团队的产出至关重要。兵熊熊一个,将熊熊一窝。我见过很多特地优良的FTO,也见过瞎整的傻X。向社会「输送一两个人才」「让一两个队员毕业」「把一两股寒气传给其他人」,不如向社会输送一个 FTO。当然对于做出问题的 FTO,咱们也要不加悭吝的给予掌声和处分。心愿各位都能找到本人心目中的「高效能团队」做出一番事件。 更多浏览研发效力组织能力建设之个性团队FeatureTeam(上) 研发效力组织能力建设之Scrum治理框架外围精华(中) 感激点赞、转载关注我,理解最新研发效力倒退动向欢送进入「DevOps研发效力群」一起探讨

October 19, 2022 · 1 min · jiezi

关于devops:十大-CICD-安全风险五

在本篇文章中,咱们将理解第三方服务的监管有余,工件完整性验证及日志可见性有余这三个要害 CI/CD 平安危险,并给出缓解相应危险的倡议与措施。 第三方服务监管有余CI/CD 攻击面包含企业资产,例如 SCM 和 CI,以及被受权拜访这些资产的第三方服务。与不受监管地应用第三方服务无关的危险依赖于第三方服务能够极其轻松地被授予对 CI/CD 零碎中资源的拜访权限,从而无效地扩充了企业的攻击面。 危险形容现在大部分企业都将第三方链接到其 CI/CD 零碎和流程,这样易于施行且易于施展间接价值,也使第三方成为日常软件开发中不可或缺的一部分,嵌入或授予第三方拜访权限的办法正变得越来越多样化。以常见的 SCM—GitHub SAAS—为例,能够通过以下 5 种办法中的一种或多种连贯第三方应用程序: GitHub 应用程序OAuth 应用程序提供给第三方应用程序的拜访令牌提供给第三方应用程序的 SSH 密钥发送给第三方的 webhook 事件配置每种办法都须要几秒钟到几分钟的工夫来施行,并为第三方提供多种性能,比方读取单个存储库中的代码,甚至是全面治理 GitHub 组织。只管这些第三方被授予对系统的潜在高级别许可,但在许多状况下,企业在理论施行之前不须要非凡许可或批准。 构建零碎还容许轻松集成第三方。将第三方集成到构建流水线中通常并不会比在流水线配置文件中增加 1-2 行代码或从构建零碎的市场装置插件(例如 Github Actions 中的操作、CircleCI 中的 Orbs)更简单。将第三方性能作为构建过程的一部分导入并执行,并能够齐全拜访执行它的流水线阶段可用的任何资源。 在大多数 CI/CD 零碎中,相似的集成办法以各种模式提供,从而使在整个软件工程生态系统中治理和保护围绕第三方应用的最小特权的过程变得极其简单。各企业也正在致力应答以下挑战: 全面理解哪些第三方能够拜访不同的零碎第三方领有哪些拜访办法、被授予的权限/拜访级别以及理论应用的权限/拜访级别影响不足对第三方施行的治理和可见性会影响企业在其 CI/CD 零碎中保护 RBAC。RBAC 的施行有余和第三方的最小特权,加上围绕第三方施行过程的治理和渎职考察有余,显著减少了企业的攻击面。鉴于 CI/CD 零碎和环境的高度互联性,单个第三方威逼可被利用,给企业造成巨大损失,例如具备写入权限的第三方存储库,攻击者能够利用该代码将代码推送到存储库,这反过来又会触发构建并在构建零碎上运行恶意代码。 倡议围绕第三方服务的管理控制应在第三方应用生命周期的每个阶段施行: 批准——建设审查程序,以确保在软件工程生态系统中的任何中央取得资源拜访权限的第三方在被授予环境拜访权限之前取得批准,并且授予他们的权限级别合乎最小特权准则。集成——引入管制和程序以放弃对集成到 CI/CD 零碎的所有第三方的继续可见性,包含: 整合办法。确保涵盖每个零碎的所有集成办法(包含市场应用程序、插件、OAuth 应用程序、编程拜访令牌等)。授予第三方的权限级别。第三方理论应用的许可级别。继续应用的可见性——确保每个第三方都被限度在其须要拜访和删除未应用和/或冗余权限的特定资源的范畴内。作为构建过程的一部分集成的第三方应在范畴内运行,对秘密和代码的拜访受限,并具备严格的出入口过滤机制。勾销配置——定期审查所有集成的第三方并删除不再应用的局部。工件完整性验证不当因为确保代码和工件验证的机制有余,工件完整性验证不当危险会导致拜访 CI/CD 流程中的零碎的攻击者将恶意代码或工件推入流水线中。 CI/CD 流程由多个步骤组成,最终负责将代码从开发人员的工作站推送到生产环境。在这个过程中外部资源和工件与从近程地位获取的第三方包和工件相结合,最终资源依赖于散布在不同步骤中的多个起源,由多个贡献者提供,这也意味着多个入口点被创立,通过这些入口点能够篡改最终资源。如果被篡改的资源可能胜利地渗透到交付过程中,很可能会以当作受信赖的资源始终流向生产环境。 影响在软件交付过程中,歹意攻击者可能会滥用不当的工件完整性验证,通过流水线传送歹意工件,最终导致恶意代码在 CI/CD 流程中的零碎上,或更糟的状况,在生产环境中执行。 倡议避免不当的工件完整性验证危险须要一系列措施,逾越软件交付链中的不同零碎和阶段。倡议企业思考以下实际: 施行相干流程和技术来验证从开发到生产的整个过程中资源的完整性。生成资源时,该过程将包含应用内部资源签名基础架构对该资源进行签名。在流水线的后续步骤中应用该资源之前,应依据签名权限验证资源的完整性。在这种状况下须要思考的一些广泛措施有: 代码签名——SCM 解决方案提供了应用每个贡献者的惟一密钥对提交进行签名的能力。而后能够利用此措施来避免未签名的提交流下流水线。工件验证软件——应用签名和验证代码和工件的工具提供了一种办法来避免未经验证的软件被交付到流水线中(如 Sigstore)。配置偏差检测——检测配置偏差的措施(例如,未应用签名 IAC 模板治理的云环境中的资源),表明资源由不受信赖的源或过程部署。从构建/部署流水线获取的第三方资源(例如作为构建过程的一部分导入和执行的脚本)应遵循相似的逻辑——在应用第三方资源之前,应计算资源的哈希值,并穿插援用官网公布的来自资源提供者公布的哈希。日志记录和可见性有余日志记录和可见性有余将给攻击者在 CI/CD 环境中执行歹意流动的机会。弱小的日志记录和可见性功能对于企业筹备、检测和考察平安相干事件的能力至关重要。尽管工作站、服务器、网络设备以及要害 IT 和业务应用程序通常在企业的日志记录和可见性程序中全面笼罩,但开发环境中的零碎和流程通常并非如此。 鉴于利用软件工程环境和流程的潜在攻打向量的数量,平安团队必须造就足够的能力以在这些攻打产生时立刻执行检测。因为其中许多向量波及利用针对不同零碎的程序化拜访,因而面临这一挑战的要害方面是围绕人工和程序拜访创立弱小的可见性。鉴于 CI/CD 攻打向量的复杂性,零碎的审计日志(例如用户拜访、用户创立、权限批改)和利用日志(例如将事件推送到存储库、执行)具备等同的重要性构建,上传工件。 ...

October 18, 2022 · 1 min · jiezi

关于devops:Gartner-权威解读-SBOM-采用率将于2025年达到60

随着古代软件开发越来越依赖于第三方资源,针对软件供应链的歹意攻打数量也随之激增。据业内权威机构 Gartner 预计,软件物料清单 (SBOM) 的采用率在 2025 年将会达到 60%。 Gartner 明确揭示软件开发企业及组织,如果想要在软件市场上保持良好的竞争力,筹备好向客户提供 SBOM 是十分必要的。 SBOM 是治理古代软件部署的复杂性和安全性的重要根底。想要成为软件产品行业中的领导者,就必须满足对技术、最佳实际和解决方案一直增长的需要,以反对 SBOM 的交付。毫不夸大的说,SBOM 对于软件供应链平安治理至关重要。Gartner 示意,只管在2022年采纳要害工作软件解决方案的企业要求在其许可或反对协定中披露 SBOM 还不到5%,但这一比例在2025年将会达到60%。 SBOM 的重要性显而易见,但也须要企业感性对待其性质和用处。SBOM 和那些解决、剖析和利用平安相干信息的工具和流程一样重要。例如软件成分剖析 (SCA) 和代码签名,这些也是残缺软件供应链的必要元素。 当先于对 SBOM 的需要Gartner 倡议软件提供商尽快满足 SBOM 披露的最低要求。与此同时,在筹备 SBOM 时,该当针对相应行业的需要和动静进行定制。只管当下软件供应商还没有收到要求披露 SBOM 的申请,但 Gartner 依然倡议软件提供商当先于对 SBOM 的需要,创立产品外部软件资产的残缺清单。 此外 Gartner 还倡议软件提供商将其每项资产归类为“商业秘密”或“齐全披露”。软件供应商可能决定从 SBOM 中排除或披露商业秘密,但通过客户许可协定中的窃密协定能够来爱护这些商业秘密。同时还倡议软件供应商创立所有内部依赖项的残缺清单,受与资产提供商签订的服务水平协定 (SLA) 束缚的依赖项应归类为“商业反对”。依赖项的任何 SLA 都应要求残缺的 SBOM 披露,而没有合同 SLA 的依赖项应归类为“自反对”。同时,软件供应商该当为这些依赖项创立一个自我反对的 SLA。该 SLA 应包含对残缺 SBOM 的发现和跟踪。 充分发挥 SBOM 的平安价值Gartner 倡议软件资产提供商该当确保他们有能力为其自主开发的资产创立残缺的 SBOM 。在满足客户对SBOM的最低需要的同时,供应商该当超过满足最根本的需要。SBOM 的目标是为软件用户提供对形成软件解决方案的资产的洞察力,以便他们致力纠正和打消通过 SBOM 披露发现的平安问题,从而防止网络歹意攻击者利用这些平安问题及破绽用于本人的攻打向量策略。 同时能够尝试制订和应用让 SBOM 可能发明更多平安价值的策略。比方将SBOM 交付与更加宽泛的平安机会,更深刻地集成到 DevSecOps 实际中,以及以将其与长期产品路线图分割起来的形式扩大和倒退 SBOM 技术。 ...

October 17, 2022 · 1 min · jiezi

关于devops:IaC示例Terraform-Ansible自动化创建K3S集群

上一篇文章介绍了一个轻量级的 Kubernetes 发行版本 - k3s 。 这篇文章,咱们将通过应用以下几个 IaC(Infrastructure as Code)工具,在本地环境(例如你的 Linux 工作台)自动化部署一个可用的 K3S 集群 Packer - HashiCorp 开源的一个零碎镜像构建工具。Terraform - HashiCorp 开源的基础设施及代码自动化管理工具。Ansible - RedHat资助的一个开源社区我的项目,IT自动化配置工具。环境需要本演示将的所有操作将在一台反对虚拟化(kvm + qemu + libvirt) Linux 主机上执行。 在 Ubuntu 上启用虚拟化环境,请参考 KVM hypervisor: a beginner's guide 。 在 Fedora 上启用虚拟化环境,请参考 Getting startyed with virtualization (libvirt) 。 在 openSUSE 上启用虚拟化环境,请参考 Virtualization Guide 。 其余 Linux 发行版,请参考相干文档。 我是在我的笔记本电脑上执行的操作,零碎是 openSUSE Leap 15.4 。 除了上述的虚拟化需要外,还须要在零碎上装置下面提到的几个工具。如果你的环境中有 LinuxBrew,则可通过 Brew 间接装置 ❯ brew install packer terraform ansible否则,请下载各自官网公布的二进制包,解压后放到 PATH 门路中。 ...

October 13, 2022 · 4 min · jiezi

关于devops:十大-CICD-安全风险四

在上一篇文章,咱们着重介绍 PPE 危险,并提供缓解相干危险的平安倡议与实际。在本篇文章中,咱们将会理解凭据应用环境治理不善与不平安的系统配置,并给出相应的危险缓解倡议。 凭据应用治理不善因为与凭据四周的访问控制、不平安的机密治理和过于宽松的凭据无关的缺点,凭据环境治理不善会给攻击者提供获取和应用分布在整个流水线中的各种机密和令牌的能力的机会。 危险形容CI/CD 环境由多个互相通信和身份验证的零碎构建而成,因为凭据可能存在的多种上下文,因而在爱护凭据方面有不小的挑战。应用程序在运行时应用应用程序凭据,流水线应用生产零碎的凭据将基础架构、工件和应用程序部署到生产环境,开发人员将凭据用作其测试环境的一部分以及代码和工件中的一部分。 这种不同的上下文,以及用于存储和应用它们的大量办法和技术,为凭据的不平安应用发明了机会。影响凭据环境平安的一些次要危险在于: 蕴含凭据的代码被推送到 SCM 存储库的其中一个分支:因为没能发现代码中蕴含的敏感信息,或未能理解相干危险,将蕴含凭据的代码推送到 SCM 存储库的分支。凭据会裸露给对存储库具备读取权限的任何人,即便从推送到的分支中删除,信息也会持续呈现在提交历史记录中,任何具备存储库拜访权限的人都能够查看。在构建和部署过程中不平安地应用凭据:这些凭据用于拜访代码存储库、读取和写入工件存储库,以及将资源和工件部署到生产环境。鉴于开发人员须要拜访大量的流水线和指标零碎,必须明确以下几个问题:在哪种状况下,应用哪种办法,应用了什么凭据?每个流水线是否仅拜访所需的凭据?流经流水线的未经审查的代码能够拜访凭据吗?这些凭据如何被调用并注入到构建中?这些凭据是否只能在运行时拜访,并且只能从须要它们的上下文中拜访?容器镜像层中的凭据:仅用于构建镜像的凭据依然存在于其中一个镜像层中,任何可能下载镜像的人都能够应用。传输到控制台输入的凭据:流水线中应用的凭据通常无意或无心地打印到控制台输入。这可能会使凭据以明文模式在日志中公开,任何有权拜访构建后果的人都能够查看。这些日志可能会流入日志管理系统,从而扩充其裸露面。未轮换凭据:因为凭据遍布整个工程生态系统,因而这些凭据裸露给大量员工和承包商。未能轮换凭据会导致领有无效凭据的人员和工件数量一直减少。对于流水线应用的凭据,如果企业秉持“未损坏就不修复”的理念进行治理,那么未轮换的凭据则会长期有效,平安危险也会随着领有无效凭据人员的数量减少而减少。影响凭据是攻击者最常利用的工具,攻击者试图将凭据用于拜访高价值资源或部署恶意代码和工件。而在凭据治理不善的开发环境中,攻击者取得了多种获取凭据的路径。最大的危险还是人为因素,因为不足平安治理凭据相干常识以及对凭据轮换可能影响流程的担心,使得凭据裸露于危险中,让许多企业的高价值资源面临因凭据裸露而受到侵害的危险。 倡议从代码到部署,倡议建设程序来继续映射软件开发生态系统中不同零碎中发现的凭据。确保每组凭据都遵循最小权限准则,确保所需权限被精准授予到相干服务的应用。防止在多个上下文中共享同一组凭据。这减少了实现最小特权准则的复杂性,并对问责制产生负面影响。倡议应用长期凭据,缩小应用动态凭据。如果须要应用动态凭据,倡议建设定期轮换所有动态凭据并检测古老的凭据的相干程序。将凭据的应用配置为仅限于预约条件(例如限定特定源 IP 或身份),以确保即便在受到破坏的状况下,泄露的凭据也不能在您的环境之外应用。检测推送到代码存储库并存储在其中的密钥。应用诸如 IDE 插件之类的控件来辨认本地更改中应用的密钥、每次代码推送时的主动扫描以及对存储库及其过来提交的定期扫描。确保 CI/CD 零碎中应用的秘密以容许每个流水线和步骤仅拜访其须要的秘密的形式限定范畴。应用内置的供应商选项或第三方工具来避免秘密被传送到将来构建的控制台输入。确保所有现有输入不蕴含秘密。验证是否从任何类型的工件(例如容器镜像、二进制文件或 Helm Chart的层)中删除了秘密。不平安的系统配置不平安的系统配置危险源于流水线中不同零碎(例如 SCM、CI、Artifact 存储库)的平安设置、配置和加固方面的缺点,这类危险往往扩充了企业的攻击面,给攻击者可趁之机。 危险形容CI/CD 环境由多个供应商提供的多种零碎组成。为了优化 CI/CD 安全性,企业及其开发团队须要高度重视流经流水线的代码和工件,以及每个独自零碎的状态和弹性。与存储和解决数据的其余零碎相似,CI/CD 零碎波及所有级别的各种平安设置和配置——应用程序、网络和基础设施,这些设置对 CI/CD 环境的平安情况和潜在危害的敏感性有重大影响。攻击者总是在寻找潜在的 CI/CD 破绽和谬误配置,这些破绽和谬误配置能够用来为他们谋取利益,比方: 应用过期版本或短少重要安全补丁的自我管理系统和/或组件。具备过于宽松的网络访问控制的零碎。对底层操作系统具备管理权限的自托管零碎。具备不平安系统配置的零碎。配置通常确定与受权、访问控制、日志记录等无关的要害平安性能。在许多状况下,默认配置集并不平安,须要优化。凭据环境治理不当的零碎——例如未禁用的默认凭据、过于宽松的编程令牌等等。尽管应用 SaaS CI/CD 解决方案打消了与零碎强化和网络内横向挪动相干的一些潜在危险,但组织仍须要高度关注并平安配置其 SaaS CI/CD 解决方案。每个解决方案都有本人的一套独特的平安配置和最佳实际,这对于放弃最佳平安状态至关重要。影响攻击者可能会利用其中一个 CI/CD 零碎中的安全漏洞来取得对系统的未经受权的拜访,甚至毁坏零碎并拜访底层操作系统。攻击者可能会滥用这些破绽来操纵非法的 CI/CD 流程、获取秘密令牌并可能拜访生产环境。在某些状况下,这些缺点可能会让攻击者有机会在开发环境内和 CI/CD 零碎的上下文之外横向挪动。 倡议保护正在应用的零碎和版本的清单,包含每个零碎的指定所有者对应的映射图。继续查看这些组件中的已知破绽。如果有可用的安全补丁,请更新易受攻击的组件。如果没有,该当思考移除组件/零碎,或通过限度对系统的拜访或零碎执行敏感操作的能力来缩小利用破绽的潜在影响。确保对系统的网络拜访合乎最小拜访准则。建设安全检查流程,来定期检查所有系统配置中可能影响系统安全情况的任何设置,并确保所有设置都是最佳的。确保依照最小权限准则授予流水线执行节点的权限。在这种状况下,一个常见的谬误配置是向开发人员授予执行节点上的调试权限。尽管在许多组织中这是一种常见做法,但必须思考到任何可能在调试模式下拜访执行节点的用户,都可能在将所有秘密加载到内存并应用节点身份时裸露所有敏感信息。因而请审慎为领有此类权限的开发人员降级权限。下一篇文章为本系列文章的最初一篇,咱们将理解第三方服务的监管有余,工件完整性验证及日志可见性有余这三个 CI/CD 平安危险及缓解相应危险的倡议与措施。

October 13, 2022 · 1 min · jiezi

关于devops:什么是特性团队-功能团队FeatureTeam

最近始终在思考如何做团队组织能力建设和如何进行决策、执行产品研发策略。因为本人始终在研发效力畛域,所以来谈谈什么是个性团队(FeatureTeam), 怎么创立个性团队以及在日常工作中如何联合 Scrum 率领团队疾速向用户交付产品价值。内容稍多,筹备分三篇来实现,本篇次要介绍个性团队/性能团队(FeatureTeam)。 为什么须要个性团队?其实,我在率领团队实现工作的时候常常遇到上面的问题? 传统的依照职能组织的团队之间,跨职能的协调和依赖治理简单,不利于跨职能、跨层级的沟通多种职能之间依赖重大,各种等待时间不利于价值流的疾速流动和承诺最终的交付工夫每个职能都在专一本人的事件,对用户价值整体交付不足关注各职能团队之间指标难以对齐每个人都对本人的事件负责,无人对最终的后果负责同时,跨职能团队之间还有一个最重要的问题就是难以应答高度不确定的问题。咱们常常会被易变、不确定、简单、含糊的问题整得焦头烂额。也正是在这样的背景下,特定团队诞生了,咱们冀望通过建设一个稳固、端到端解决问题的团队来帮咱们解决这些事件。个性团队进步了咱们应答高度不确定问题的应变能力,让咱们缓缓靠近最初的「正确答案」,让咱们在某种程度上具备了「可预见性」。 什么是个性团队?定义:个性团队是一个长期稳固、跨职能、跨组件,继续端到端交付用户价值的团队。 特点:长期、稳固:这不是一个长期拼凑接私活的装修队,而是须要长期一起工作解决各种问题的「特种部队」。咱们个别不超过两个披萨12集体。跨职能、跨组件:一专多能T型人才;所有信息团队外部共享。推心置腹,不搞信息差。既然咱们要一起去打硬仗,那么咱们之间都是能够把后背相互托付的人。上到开飞机飞船下到开坦克潜艇样样精通,前后端通吃,产品经营运维一起抓。端到端的交付:咱们是一支能够交付用户价值的团队,从理解用户、梳理需要到最初价值交付咱们都能够做,需要来了拉出去就无能。这就是咱们要说的救人斩首能够做,经济建设也能行。外围价值最大化响应速度最大水平缩小内部、外部依赖最大水平升高沟通老本益处团队内能够做到端到端,所以缩小了期待,交付速度快缩小了团队之间依赖,打算更容易更有保障责任范畴的扩充,各种不同畛域的专家在一个团队,减少了个人成长的机会团队外部疾速沟通、疾速响应用户的诉求长期稳固的单干,成员归属感加强团队成员间接面对用户,更加粗浅理解本人工作的业务,同时感触到本人工作的价值团队成长快,FT 运行一段时间,团队每个人产出都有晋升FT对每个人都要求很高,每个人都有全局视角,有把事搞定的能力,疾速学习的能力以用户为核心的性能个性驱动团队运行问题FT 对团队每个人要求都很高,要有一直学习的能力,自我驱动和被动承当,但不是每个成员都能适应各个FT都会针对本人的团队十分理论的做出决定,在技术栈抉择、规范性听从上个别不是很重视,各个FT之间交加很少,反复造轮子在劫难逃长时间在一个 FT 中工作,局部队员可能会对本 FT 做的事件失去趣味工作边界并不是很清晰,两头含糊地带须要更多地施展踊跃主动性长期高强度的端到端用户价值的交付,让咱们把注意力全副集中在事上,对人的关心度升高难以齐全闭环。对于专业性很强、难以短时间把握的职能,还是须要业余的小伙伴来反对,比方运维、DBA、设计师当然这些问题都是可解的,我在下篇文章中会具体介绍。 什么时候采纳个性团队组织形式?在开发新的产品、新的业务进入新的市场业务倒退初期,须要疾速关上场面用户数快速增长、须要疾速响应什么中央适宜个性团队?守业外部守业外部新业务个性团队里边的人员构成?个性团队里失常状况下只有两种角色,FTO,FT队员 FTO:团队的「CEO」,能决策、会执行、要负责 搭班子:负责整个FT的搭建、对外协调,对内沟通,对整个团队负责、对后果负责定策略:整体把握业务的方向,敢于做决策并对后果负责;在无限资源、工夫、范畴内取舍,推动特定问题的解决带队伍:负责团队的治理、躬身入局、敢于当先FT队员复合型人才,跨职能跨组件端到端的解决问题,主人翁精力(Ownership),自驱力 个性团队带来的老本全能型人才带来对每个人各方面要求都很高,人力老本是有所回升的。就像特种部队一样,想造就出一个能征善战的特种部队也是十分不容易的。齐全闭环的 FT,人员利用率未必是最高的。因为很多是跨职能跨组件,每个人要相互备份,每个人要理解得也多,就须要付出更多的精力。比方A模块是小王写的,这个时候小李要去解决个问题,这个时候必定比小王本人去修效率要降落。同时前后端通吃的复合型人才写前端的时候也未必有一个更业余的前端写的溜写的好,找个前端来兴许更快更好。单FT负责整个产品当一个FT 能够负责整个产品的时候咱们个别采纳下面的模式。 FTO个别由产品经理负责FT 负责一个残缺的产品, FTO 就是 Scrum PO(Product Owner)FTO视状况决定是否须要设置 Scrum MasterFTO视状况决定是否须要设置研发 Leader多FT负责整个产品当产品规模较大,繁多FT曾经无奈撑持所有「以用户为核心的性能」,而因业务又须要同时撑持时,咱们通常会建设多个FT来撑持。 多FT的模式和单FT还是有很大不同的。 团队内不再是全能型的人才(太贵了),转而由各个职能团队反对,比方前端、后端、挪动端、产品、QA、运维、设计师(UI,交互等)、经营、PMO等FTO个别由产品经理负责,也可独自指定FTO 不是产品经理负责时,FT中须要有PO(Product Owner)FTO负责本FT团队的产出,仍然对最初的后果负责FTO不再负责人才培养,转而移交到职能部门,但对人员有考核权,且权重高于职能线(FTO是拿后果的);FTO视状况决定是否须要设置独自的产品/前端/后端/QA/挪动端等负责人;设置后各负责人须要虚线汇报FTO,FTO对职能负责人有考核权,且权重高于职能线FTO不再负责我的项目协同,转而移交到PMO,PMO对FTO实线/虚线汇报;虚线汇报时,FTO对PMO有考核权,且权重高于职能线对于如此大的产品,FT成员要撑持端到端的性能产出,对整个产品须要理解,学习老本高,学习曲线长各FT共用雷同的源码库,须要更精密的分支治理和更好的合作,同时对代码品质要求更高,要有准入规范等各FT的技术栈抉择须要达成共识,可由技术委员会或者架构部来协调和确认各FT的基础设施、撑持平台也会由独自的研发效力团队来负责文章小结个性团队也不是银弹,然而确实帮咱们解决了很多的问题,比方高效沟通、疾速响应、以及升高内外依赖等,尤其是在以用户为核心的价值疾速交付上让咱们更加从容地应答不确定的问题,当然个性团队也存在它本人的问题比方单FT老本高、队员长期做一件事失去趣味、人文关心欠缺,多FT的学习老本和基础设施建设等。我下篇文章会联合 Scrum 来说一下单FT是怎么运行的,这样你读起来更能有体感。 参考资料Feature Team 疾速响应团队解脱简短研发体制 当议论Feature Team时咱们在谈些什么 互联网公司研发效力/工程效率团队建设和布局 研发效力团队规模、职能划分和优劣势剖析概述 研发效力之产品经营 研发效力之技术治理 感激点赞、转载关注我,理解最新研发效力倒退动向欢送进入「DevOps研发效力群」一起探讨

October 13, 2022 · 1 min · jiezi

关于devops:10-Best-DevOps-Tools-for-Startups

Author's note: the opinions and thoughts expressed in this blog post (including but not limited to the choice of tools, reviews/comments on tools, comparisons, etc.) reflect only the author's views, which are my own and don't represent either DevStream or my employer's opinion.OK. You are in a small start-up, and you want to move fast. To move fast, you will need automation instead of doing stuff manually. So, it would be best if you had a bunch of DevOps tools that can accelerate your software development lifecycle (SDLC.) ...

October 12, 2022 · 11 min · jiezi

关于devops:十大-CICD-安全风险三

在上一篇文章,咱们理解了依赖链滥用和基于流水线的访问控制有余这两大平安危险,并给出缓解危险的平安倡议。本篇文章将着重介绍 PPE 危险,并提供缓解相干危险的平安倡议与实际。 Poisoned Pipeline Execution (PPE) 危险指的是攻击者可能拜访源代码控制系统,但无法访问构建环境,通过将恶意代码/命令注入构建流水线配置来操纵构建过程,实质上是“中毒的”流水线和运行恶意代码作为构建过程的一部分。 危险形容PPE 危险通常存在代码仓库中,可控对应的 CI 管道配置文件,通过批改 CI 配置文件达到执行对应命令的目标。有权操作 CI 配置文件或 CI 流水线工作所依赖的其余文件的攻击者,能够将歹意命令置入这些文件,通过执行这些歹意命令,最终“毒化”执行这些命令的 CI 流水线。执行未经审查的代码的流水线,比方一些间接由拉取申请或提交到任意存储库分支触发的流水线,因为在设计上蕴含未经任何审查或批准的代码,更容易受到 PPE 危险的影响。一旦可能在 CI 流水线中执行恶意代码,攻击者就能够在流水线身份的上下文中进行各种歹意操作。 PPE 的三种类型间接 PPE(D-PPE)在 D-PPE 场景中,攻击者批改他们有权拜访的存储库中的 CI 配置文件,通过间接将更改推送到存储库上未受爱护的近程分支,在提交 PR 时随着分叉的更改而变动。因为 CI 流水线执行是由“push”或“PR”事件触发的,并且流水线执行是由批改后的 CI 配置文件中的命令定义的,一旦构建流水线被攻打,攻击者的歹意命令最终会在构建节点中运行触发。 间接 PPE(I-PPE)在以下几种状况下,即使攻击者可能拜访 SCM 存储库,也无奈应用 D-PPE: 流水线配置为从同一存储库中独自的受爱护分支中提取 CI 配置文件。CI 配置文件存储在与源代码不同的存储库中,则用户没有间接编辑它的选项。CI 构建是在 CI 零碎自身中定义的——而不是在存储在源代码中的文件中。在这几种状况下,攻击者就会抉择向流水线配置文件援用的文件中注入恶意代码来毁坏流水线: make:执行“Makefile”文件中定义的命令。从流水线配置文件中援用的脚本,与源代码自身存储在同一存储库中(例如, python myscript.py - myscript.py 将被攻击者操纵)。代码测试:在构建过程中在利用程序代码上运行的测试框架依赖于专用文件,这些文件与源代码自身存储在同一存储库中。可能操纵负责测试的代码的攻击者可能在构建中运行歹意命令。主动工具:CI 中应用的 Linter 和平安扫描器通常也依赖于存储库中的配置文件。很多时候这些配置波及从配置文件中定义的地位加载和运行内部代码。因而,在 I-PPE 中,不同于将歹意命令直接插入流水线定义文件来毁坏流水线,攻击者通过将恶意代码注入到配置文件援用的文件中,一旦触发流水线并运行相干文件中申明的命令,恶意代码最终会在流水线节点上执行。 公共 PPE(3PE)执行 PPE 攻打须要拜访托管流水线配置文件的存储库或其援用的文件。大多数状况下,只有开发人员领有此类许可,也就是说攻击者必须要取得开发工程师对存储库的许可和权限能力执行间接或间接 PPE 攻打。 然而,在一些状况下,互联网上的匿名攻击者能够应用“中毒的” CI 流水线:公共存储库(例如开源我的项目)通常容许任何用户做出奉献,通过创立拉取申请,倡议对代码进行更改。这些我的项目通常应用 CI 解决方案自动测试和构建,与公有我的项目相似。如果公共存储库的 CI 流水线运行匿名用户倡议的未经审查的代码,它很容易受到公共 PPE 攻打,或者简称为 3PE。如果易受攻击的公共存储库的流水线在与公有存储库雷同的 CI 实例上运行,这也会裸露例如公有我的项目的敏感信息这类的外部资产。 ...

October 12, 2022 · 2 min · jiezi

关于devops:十大-CICD-安全风险一

CI/CD 环境、流程和零碎是古代软件组织的外围。他们将代码从开发工程师的工作站传递到生产环境。联合 DevOps 和微服务架构的衰亡,CI/CD 零碎和流程重塑了工程生态系统: 技术堆栈更加多样化,无论是编码语言,还是流水线中进一步采纳的技术和框架(例如 GitOps,K8s)。采纳新的语言和框架的速度越来越快,没有重大的技术阻碍。自动化和基础设施即代码(IaC)实际的应用有所增加。第三方,无论是内部提供商的模式还是代码中的依赖关系,都已成为任何 CI/CD 生态系统的重要组成部分,新服务的集成通常只须要增加1-2行代码。以上这些特色容许更快、更灵便和多样化的软件交付。然而,也为攻击者提供了许多新的路径和机会,减少了企业的攻击面。 本系列文章零碎整顿与 CI/CD 相干攻打媒介进行的宽泛钻研以及安全漏洞剖析后果,帮忙企业及其开发团队更好地爱护其 CI/CD 生态系统。 流程管制机制有余流控机制有余(insufficient flow control)指的是因为不足强制执行额定批准或审查机制,攻击者在 CD/CD 过程(SCM、CI、Artifact 存储库等)取得零碎权限,轻松将恶意代码或工件轻松推送到流水线中的问题。 影响攻击者取得能够拜访 SCM、CI 或流水线上游零碎的权限,便可能利用有余的流控机制来部署歹意工件。一旦创立,工件就会通过流水线推送到生产环境且无需任何批准或审查。以下的状况可能呈现: 将代码推送到存储库分支,该分支会通过流水线主动部署到生产环境。将代码推送到存储库分支,而后手动触发将代码运送到生产环境的流水线。间接将代码推送到实用程序库,供在生产零碎中运行的代码应用。滥用 CI 中的主动合并规定,该规定会主动合并满足一组预约义要求的拉取申请,从而推送未经审查的恶意代码。滥用分支爱护规定有余。例如,排除特定用户或分支来绕过分支爱护,从而推送未经审查的恶意代码。以构建环境创立的非法工件的名义将工件上传到工件存储库,例如包或容器。在这种状况下,不足管制或验证可能会导致工件被部署流水线拾取并部署到生产中。拜访生产并间接更改利用程序代码或基础设施(例如 AWS Lambda 函数),无需任何额定的批准/验证。倡议建设强化流水线流控机制,以确保没有任何集体或程序可能在没有内部验证或验证的状况下通过流水线传送敏感代码和工件。企业能够通过施行以下措施来实现: 在用于生产和其余敏感零碎的托管代码的分支上配置分支爱护规定。尽可能防止将用户帐户或分支排除在分支爱护规定之外。如果用户帐户被授予将未经审查的代码推送到存储库的权限,务必确保这些帐户无权触发连贯到相干存储库的部署流水线。限度主动合并规定的应用,并确保无论在何处应用,要实用于最大量的上下文。彻底查看所有主动合并规定的代码,确保这些不会被绕过,并防止在主动合并过程中导入第三方代码。在实用的状况下,避免帐户在未经额定批准或审查的状况下触发生产构建和部署流水线。只容许工件在由事后批准的 CI 服务帐户创立的条件下在流水线传输。避免通过其余账户上传的工件在没有二次审核和批准的状况下在流水线中推送。检测并避免生产中运行的代码与其 CI/CD 之间的偏差和不统一,并批改任何蕴含偏差的资源。身份和拜访治理有余身份和拜访治理有余(inadequate identity and access management)的危险源于治理散布在工程生态系统中不同零碎(从源代码管制到部署)的大量身份的治理难题。如果身份和拜访治理不善,企业受到攻打威逼危险将会大大增加。 软件交付过程由连贯在一起的多个零碎组成,目标是将代码和工件从开发环境转移到生产环境。每个零碎都提供多种拜访和集成办法(用户名和明码、集体拜访令牌、市场应用程序、oauth 应用程序、插件、SSH 密钥)。不同类型的帐户和拜访办法可能具备其独特的配置办法、安全策略集和受权模型。这种复杂性为在整个身份生命周期中治理不同身份以及确保其权限与最小特权准则保持一致带来了微小挑战。 挑战在典型环境中,SCM 或 CI 的普通用户帐户是高度宽松的,因为这些零碎传统上并不是平安团队的次要关注畛域。这些身份次要由须要可能在代码和基础架构中进行重大更改的工程师应用。CI/CD 生态系统中围绕身份和拜访治理的一些次要问题和挑战包含: 过分宽松的身份 – 在 SCM 中,确保每个用户和应用程序身份仅被授予所需的权限,并且仅针对其须要拜访的理论存储库授予权限并非易事。过期的身份 — 不沉闷和/或不再须要拜访但没有针对所有 CI/CD 零碎勾销配置的人员和程序帐户的员工/零碎。本地身份 — 没有与集中式 IDP 联结拜访的零碎,创立在相干零碎内本地治理的身份。本地帐户在执行统一的安全策略(例如明码策略、锁定策略、MFA)以及正确勾销对所有零碎的拜访权限(例如员工到职)时带来挑战。内部身份应用非组织领有或治理的域中的电子邮件地址注册的员工—在这种状况下,这些帐户的安全性高度依赖于调配给他们的内部帐户的安全性。因为这些帐户不禁组织治理,因而不肯定合乎组织的安全策略。 内部协作者 — 一旦授予内部协作者对系统的拜访权限,零碎的安全级别就源自内部协作者的工作环境级别,超出了组织的管制范畴。自注册身份 — 在容许自注册的零碎中,无效的域地址通常是自注册和拜访 CI/CD 零碎的惟一先决条件。应用默认/根本权限可能会扩充潜在的攻击面。共享身份 — 在用户/应用程序之间共享的身份,因为多人/应用程序应用对立身份账户,在进行追踪和考察时无奈进行无效分辨,导致问责制度生效。影响在 CI/CD 生态系统中存在成千盈百个身份(人类和程序化身份),加上不足弱小的身份和拜访治理实际,以及适度宽松帐户的广泛应用,导致系统上的任何用户帐户都能够为环境授予弱小的性能,并且能够作为进入生产环境的通行证。 ...

October 10, 2022 · 1 min · jiezi

关于devops:GitLab-Jenkins-Harbor-工具链快速落地指南

一、明天想干啥?明天咱们来聊聊如何疾速落地“GitLab + Jenkins + Harbor 工具链”。 请留神这里的关键词:疾速(有多快呢?我心愿这个工夫是5分钟。) 我晓得你想要一条闪闪亮的工具链来撑持你的利用 CICD 流程,你想要“最佳实际”,你想要既灵便又简略还易保护,你有一肚子的既要,又要,还要…… 行,明天我就给你一个“既有,又有,还有”的《GitLab + Jenkins + Harbor 落地计划》。 二、明天干点啥?明天咱们要搭建一条怎么的工具链呢?且看效果图: 首先咱们须要实现 GitLab、Jenkins 和 Harbor 三个工具的部署;接着咱们须要在 GitLab 上创立一个代码库,并且在 Jenkins 上创立相应的流水线,这个流程最好也自动化(的确能够自动化);而后适当地配置这三个工具,实现如下 CI 流程: 当用户推送代码到 GitLab,也就是 GitLab 上相应代码库产生 push 或者 merge 事件的时候,这个事件可能主动触发 Jenkins 上的流水线执行;Jenkins 上流水线执行的后果可能回显到 GitLab;Jenkins 上实现了编译、构建等等流程后,最终制品是一个容器镜像,这个镜像能够被推送到 Harbor 上。三、明天怎么干?我筹备应用云原生的形式来部署这三个工具,起因不赘述。 当然我也晓得少数状况下你并不需要思考 GitLab 如何部署,因为95% 的概率你们公司曾经有可用的 GitLab 了,或者你们思考应用 SaaS 版的 GitLab。外加 Kubernetes 上部署 GitLab 的复杂度不低,运维老本高,所以,GitLab 的“高可用部署”不是本文重点,咱们把重点放在如何部署和配置好 Jenkins + Harbor,而后对接 GitLab,走通一个 CI 流程。 综上,明天我筹备 sale 的部署模式是: GitLab:DockerJenkins:Helm(Kubernetes)Harbor:Helm(Kubernetes)3.1、惯例打法如果依照常理出牌,这时候咱们应该是翻阅三个工具的官网,学习部署流程和配置步骤,而后总结最佳实际,一步步试错,一步步改良…… 听起来就简单。 ...

October 9, 2022 · 7 min · jiezi

关于devops:Google-发布DevOps-2022现状报告

在过来的八年中,寰球超过 33,000 名专业人士参加了Accelerate State of DevOps 考察,使其成为同类钻研中规模最大、运行工夫最长的一项。Accelerate State of DevOps 报告提供了数据驱动的行业洞察力,这些洞察力查看了推动软件交付以及经营和企业绩效的能力和实际。 在2021 年,有超过220亿条记录因数据泄露事件而裸露,数家大公司也因而蒙受微小影响和损失。因而,安全性依然是企业的首要思考因素,同时企业也致力于确保客户数据的平安以及他们的业务失常运行。 综合思考到信息安全现状,Google Cloud 的 DevOps 钻研和评估 ( DORA ) 团队在9月28日公布的 2022 Accelerate State of DevOps Report(文末查看获取报告形式)中着重关注平安问题。 爱护软件供应链为了剖析平安与 DevOps 之间的关系,报告中探讨了软件供应链平安这一主题,该主题在前几年的考察中只波及到了一小部分。DORA 团队应用了 Google 定义的 SLSA框架和美国国家标准研究院(NIST)的平安软件开发框架(SSDF)的供应链级别来评估组织,综合这两个框架可能摸索影响组织如何施行和思考软件平安实际的技术和非技术方面。 总体来说,报告发现新兴平安实际的宽泛采纳超乎预期。在 SLSA 和 NIST 的 SSDF 推广的所有实际中,应用应用程序级平安扫描作为生产公布的继续集成/继续交付 (CI/CD) 零碎的一部分是最常见的做法,63% 的受访者示意这是“十分”或“齐全”成立。此外,保留代码历史和应用构建脚本也很成熟,而签订元数据(metadata)和须要两个人的审查过程还有很大的增长空间。 报告指出,企业在实现应用程序平安方面面临的最大挑战更多地与文化无关,即高信赖、低指责的文化(high-trust, low-blame culture),而不是任何技术缺点。与重视势力或规定的低信赖、高指责文化相比,重视绩效的人更有可能采纳新兴的平安实际。该报告指出,专一于减速软件交付而不施行有意义的 DevSecOps 最佳实际的企业发现自己处于一个事与愿违的恶性循环,导致应用程序在生产环境中胜利部署的频率升高。 不仅如此,报告结果表明,专一于建设有意义的平安实际的团队缩小了开发人员的倦怠。为此,数据表明企业文化和古代开发流程(例如继续集成)是企业软件平安的最大驱动力,同时也是企业寻求改善其平安情况的最佳终点。 2022 新发现往年 DORA 团队继续关注和摸索软件交付和经营体现。在报告中,将应用四个要害指标对 DevOps 团队进行分类:部署频率(deployment frequency)、变更前置工夫(lead time for changes)、均匀复原工夫(time to restore service)和变更失败率(change failure rate),以及 DORA 团队去年引入的第五个指标,可靠性(reliability)。 ...

October 9, 2022 · 1 min · jiezi

关于devops:SBOM缓解软件供应链风险的关键

软件蕴含大量且范畴宽泛的组件、局部和相互依赖关系。须要无效缓解与应用软件相干的平安危险;须要恪守与组件相干的许可证。通过第三方代码(包含开源软件 (OSS))理解产品中所有我的项目的出处至关重要,无论这些元素源自企业的团队还是团队之外。确保安全的最佳办法是保护软件中所有组件的以后“成分列表”列表——软件资料清单 (SBOM)。 什么是 SBOM?就像食品的成分列表一样,SBOM 就是软件中组件和服务的列表。SBOM 相似于制作和产品开发中的供应链文档。在产品开发供应链中,制造商应用特定供应商的整机,装置组件来构建产品,而后跟踪产品从制造商到购买它的零售店的旅行历史。与此相似,网络环境中的服务器机器是应用交付给制造厂的供应商部件构建的。服务器构建实现,而后从一个地位挪动到另一个地位,直到它达到装置它的数据中心。这个过程中的每一步都是供应链的一部分。 SBOM 是进步整个软件平安供应链透明度和问责制的重要一步,但这只是在软件市场实现有意义的平安透明度的第一步。除了成分之外,软件消费者还应该分明地理解为软件构想的威逼模型、现有的平安机制、执行的平安测试以及开发人员是否承受过培训。 在之前的文章 OpenSSF平安打算:SBOM 将驱动软件供应链平安 有提到,目前美国联邦政府采取了积极主动的措施,要求政府机构生产和生产的所有软件都应用 SBOM。《对于改善国家网络安全的行政命令》指出,网络攻击的频率和复杂性的减少催化了公共和公有部门联手爱护软件供应链的场面。这也标记着 SBOM 驱动的将来曾经到来。 SBOM 的劣势SBOM 是平安团队的现实工具,他们须要深刻理解第三方软件危险以理解他们所应用的版本、任何许可影响以及可能减少平安债权的其余依赖项。最初,SBOM 帮忙事件响应团队辨认破绽的起源以及是否被利用,以便疾速告诉客户。随着开源库的激增和 log4j 等宽泛应用的库的大规模开发,SBOM 能够帮忙组织在其应用程序组合中管制开源。以下是 SBOM 的劣势: SBOM 能够帮忙组织优先思考危险最高的开源应用。第一个指标是杜绝应用具备已知破绽的库,并随时关注每个开源库的最新版本。SBOM 在危机状况下也十分有用。当库中的新破绽被披露时,组织必须可能疾速精确地追踪该版本在其企业中的应用地位,这一点至关重要。应用来自企业各团队的 SBOM 数据并继续更新是疾速响应的要害。最初,通过将 SBOM 信息提供给软件消费者,这样无效解决了软件市场中的信息不对称问题。能够拜访无关应用程序安全性的残缺信息(包含 SBOM 中的库信息)的消费者能够做出理智的决定,同时也激励开发者创立平安可信赖的杰出软件。 SBOM 的作用SBOM 是一种正式且可查问的记录,其中蕴含用于构建软件的各种组件的详细信息和关系,包含开源软件和所有引入的第三方软件。SBOM 提供的清单是平安软件开发框架(secure software development framework)的要害因素,有助于在软件开发过程中检测破绽,而后在软件生命周期中施展继续作用。 软件部件从各种不受监管的起源引入应用程序:供应商代码、合作伙伴代码、开源我的项目和外部开发。开发人员常常应用来自各种中央的代码(开源和第三方代码),这些代码不像商业软件那样具备雷同的入站管制和审查。开源和第三方代码来自出名生态系统(如 Apache Software Foundation 和 Eclipse Foundation)和权威工件存储库,包含 Maven Central (Java)、NuGet (.NET)、npm (JS)、PyPI (Python) 、RubyGems (Ruby) 等等。有时,代码还能够通过寰球各地的集体开发人员进入企业,这些开发人员将他们的代码托管在源代码存储库上,例如 GitHub 或 GitLab。 可能拜访此代码中反映的翻新和常识通常对用户无益,但也提出了一个须要解决的重要问题:代码中蕴含什么?这就是 SBOM 的亮点,借助 SBOM,软件公司能够辨认: 软件中的组件/成分这些组件来自哪里每个组件的许可证信息软件(及其运行的设施)的安全漏洞状态哪些局部须要评估和补救(以及您在此过程中的地位)向客户和合作伙伴交付的合规性工件美国国家电信和信息管理局 (NTIA) 概述了 SBOM 的最低因素,例如数据字段(名称、许可证和版本)。目前已存在多种 SBOM 的格局,例如 CycloneDX、OpenChain 和 SPDX,行业也正在致力标准化 SBOM 的格局。SBOM 以多种格局创立和保护,有时在比拟或编译 SBOM 时会遇到挑战。 ...

September 30, 2022 · 1 min · jiezi