关于devops:大型企业如何实现数据驱动的场景化服务

导语:每一家企业都渴望实现商业翻新,它意味着,企业通过其独有的价值生产零碎,为客户提供了新的商业价值。一旦实现了商业翻新,往往就会极大地减速企业的倒退,甚至间接帮忙企业找到增长的“第二曲线”。那么应该如何实现商业翻新呢?有意思的是,最近十年,中国企业界曾经很少探讨这个话题。一方面是因为一些根底翻新曾经实现,而深层次的翻新时机还没有被发现;更重要的起因则是商业翻新太难得,近乎可遇而不可求。事实,让企业家们不得不退让。 好在,数字经济时代的到来,彻底扭转了这一场面。除了陈词滥调的翻新理念、翻新文化,咱们找到了另外一条门路,能够将商业翻新具象化、流程化,甚至确定化。 这条路是通过大数据、人工智能、云计算、物联网、5G、挪动互联网、区块链等最新技术,构建一个集工具、能力和资源服务为一体的云服务集群,使能企业商业翻新倒退。现阶段,有十分多的 B 端产品在依照此门路疾速落地,而用友 YonBIP 就是其中最典型,也是最优良的一个。 用友 YonBIP 的可贵之处,在于其跑通了从场景化服务到数据驱动,再到实时决策,终至商业翻新的整条门路,并在场景化服务局部有着人造的壁垒和劣势。 如何做好八大畛域的场景化服务场景化服务是商业翻新之路的终点,也是所有使能平台都要思考到的问题。它就像一双鞋子,只有足够合脚,能力谈及远途。 但也恰好是“合脚”两个字,难住了大部分使能平台的产品经理。这其中有一个很简略的逻辑:如果你长年保护 CRM 零碎,对 CRM 畛域的客户需要比拟相熟,在供应链治理畛域就很难保障业余;如果你长年保护一套供应链管理系统,对 CRM 零碎就未必相熟。这是普通人在精力和工夫层面的悖论,与企业需要不符 —— 繁多畛域的服务,很难跳出工具层面,实现企业级的商业翻新。 用友 YonBIP 的特别之处,在于其依靠的是整个用友超过三十年的技术积攒以及企业级客户实际。目前,用友 YonBIP 曾经成为集营销云、洽购云、制作云、供应链云、企业金融云、财务云、人力云、协同云于一体的商业翻新平台,其中波及到对八个畛域的全面场景化形象,对于很多企业而言,其工作量是无奈设想的。预计也只有用友有底气承诺,相干服务畛域全副有理论的研发和产品化教训,能够做出适应客户实在需要的场景化服务。 用友网络副总裁刘剑锋说:咱们就须要尽量用一套架构和是中台复用的形式来撑持多个市场或客群的须要。这对咱们产品架构的形象能力要求更高,也要求产品经理能精确辨识不同客群的客户需要。所以咱们有 YonBIP 产品管理部,也专门有 YonSuite 产品管理部,剖析中型企业在营销、洽购畛域到底须要什么?大型企业又须要什么?大家各自为本人的客群负责,最初架构师会把所有的需要再形象成一个公共的产品。 这里,YonBIP 对不同的企业规模也做了细分。以财务云为例,中型企业可能只须要根本的财务、报销等流程治理,更轻便简洁。大型企业的财务云,则会有共享服务中心的需要,共享服务中心会把企业上司的二级、三级公司的财务报表集中到一起,对立解决所有公司的财务工作。没有在行业内经验过摸爬滚打,很难精确感知到。场景化的另一个因素,在于企业的中台能力要足够强,不然无奈提供足够的技术和能力撑持。在分辨不同场景差别点的同时,可能对公共能力做好形象,造成中台,也是商业翻新平台的能力体现。 YonBIP 有三中台、三平台,“三中台”包含业务中台、数据中台和智能中台,而“三平台”包含技术平台、低代码开发平台、连贯集成平台。而业务中台中蕴含了一个利用平台,会从企业、组织、人员、业务主数据、权限、流程等维度做数字化建模,造成数字化建模平台,进一步增强 YonBIP 的场景化能力。 低代码开发平台和连贯集成平台、 YonStore 等生态服务,则进一步笼罩了客户的其余需要,以高度灵便的定制服务,最大水平适配客户的业务场景,造成场景化服务的闭环。 数据驱动与实时决策对场景的形象,是外功;场景之下的数据驱动和实时决策,是内功。 数据驱动与流程驱动是相辅相成的概念,咱们并非不再须要流程驱动,而是须要数据驱动的办法和理念一起参加企业经营。 ERP 是典型的流程驱动场景 —— 企业接到订单后,订单的履约流程都是当时定义好的。上游实现了工作,零碎会主动告诉上游,什么工夫做什么事,都有明确的标准。 而数据驱动的奥义,在于通过数据资产的积攒,对流程进行优化,并实现商业翻新。 刘剑锋举了个例子: “2018 年,咱们翻新了工业互联网畛域的 AIoT 平台,采集了很多设施运行、以及与品质、环境相干的数据。基于这些数据,咱们会重点剖析企业如何优化生产过程,比如说,剖析生产流程,进步产出率;剖析品质数据,晋升产品质量;剖析环境数据,管制环保排放危险;剖析设施运行数据,针对性地去做设施的培修保护,缩小设施的复工……基于数据的优化计划是十分多的。”YonBIP 的数据中台以数据挪动、数据仓库、大数据和人工智能等数据加工解决技术为根底,次要提供主数据管理、数据挪动、画像标签、关系图谱和智能剖析服务等产业规范服务。 用业务数据化、数据资产化的思维来设计企业服务。当企业须要业务数据来撑持智能决策时,数据中台先对数据进行整合、荡涤、剖析、计算,而后智能剖析层再应用相干模型来做决策。而这种数据驱动,也不仅限于企业外部。 产业互联网是 YonBIP 产品设计的重要出发点。当初是数智化时代,很多企业都是“社会化的无边界企业”,心愿解决的问题曾经不仅限于外部资源管理。所以,YonBIP 除了解决企业外部问题,还在解决企业之间的数据连贯问题,心愿通过这些数字化的连贯,实现更大范畴数据的流转,实现更高的合作效率与业务的协同效率,实现产业链上资源的优化配置。当然,在数据开始最大范畴的流动后,实时化就变得十分重要,这也是 YonBIP 产品研发的核心理念。“咱们最常看到的数据分析服务,是做数据的可视化,把数据记录下来了,能出报表,能出一个比较简单的剖析,然而都是预先的。CEO 看到数据当前,得悉企业的经营状况呈现了问题,但要留神,问题曾经产生了,只能补救,”刘剑锋说,“其实企业更心愿用数据做实时预警,提前做好管制,一旦问题数据呈现,立即预判后续后果,当下就采取措施。”而 YonBIP 也在这种理念的领导下,构建了全流程的实时数据服务,所有业务流程都是实时处理,实时连贯和应用数据资产,实现数据的实时流转。比方在洽购云、财务云,供应商的洽购、结算、对账都是线上实时进行,依据收款协定,按对账后果开发票,实时验证,实时会计,让发票入账。不须要补录发票,不须要补录订单,不须要补录信息。甚至收付款也因为连贯了 1700 多家银行,能够做到实时结算。保证数据驱动,实时决策理念的全面落地。 商业翻新的最终实现场景化服务、数据驱动、实时决策,把商业翻新从一个形象的后果问题,变成了一个过程问题。企业通过高度适配的场景接入,用数据驱动优化流程,用实时决策输入商业价值,最终能力实现商业翻新。 “治理的改革、业务的翻新,都叫商业翻新,”刘剑锋说,“但目前很多企业外部在 营销、制作、服务、人力 、财务、等各个领域往往各有一套零碎,数据并没有齐全买通,每一个烟囱零碎有本人的数据分析后果,看到的数据往往不是企业整体,而是一个点,或者是一个侧面。” ...

January 11, 2022 · 1 min · jiezi

关于devops:2021-年-25-大-DevOps-工具下

DevOps 正在扭转寰球软件开发的状态,DevOps 正以某种模式无效地进步进步寰球软件公司的上市速度、可销售性、翻新和产品质量。 2021 年是 DevOps 的重要一年。因为 DevOps 逾越开发、经营、IT、平安和产品团队等等,以及软件开发的不同阶段,因而有大量工具可供选择。 本文介绍目前市场上可用的一些顶级 DevOps 工具,同时牢记 CI/CD 生命周期的重要类别。上篇为配置管理、构建、源代码、部署工具,本篇次要是破绽治理、品质、监控、合作工具。 网络威逼及破绽治理TwistLock对基于容器的应用程序来说,TwistLock 提供了威逼和破绽。该服务以其与 Kubernetes 和 Docker 容器的集成而闻名。TwistLock 当初归 Palo Alto Networks 所有,通过其运行时利用平安爱护和容器主动扫描进行安全检查。 TwistLock 有一个弱小的文档,它易于部署并强制优化资源耗费。它还以其 CI/CD 管道集成、对容器平安协定的强合规性和图像扫描而闻名。 TwistLock 还以其精密的平安剖析而闻名。该服务还用 AI 性能来理解环境,只管有些公司曾经发现,它主动触发的 cron 作业十分令人困惑。 他们还提供基于 SaaS 的平安扫描(prisma 云)和本地解决方案。 SysdigSysdig 是一种用于云基础架构、服务和应用程序的监控工具。Sysdig 通常用于对PaaS基础设施进行容器平安确认、监控及监控安顿。 Sysdig 还可用于监控 OpenShift 集群,因为它提供粒度数据来剖析指标。 使 Sysdig 怀才不遇的是其容器监控与编排层的弱小集成。 如果你想深刻理解过程网络流量,Sysdig 也很有用。Sysdig Opensource 容许在内核零碎调用级别权限以获取主机的详细信息。捕捉信息过程也能够通过 DaemonSet 或间接代理过程主动部署为 Docker 容器。 AnchoreAnchore 是一个残缺的容器平安工作流解决方案,可与各种开发工具和平台无缝集成。Anchore 为一系列不同的应用程序提供定制的容器检查和合规性解决方案,使团队可能合乎行业平安规范。平安团队能够审计和验证整个组织的合规性。 性能包含: 反对webhook,包含云托管或本地 Kubernetes 环境和 CI/CD 平台基于策略的安全性和合规性查看: 破绽扫描机密和明码操作系统包第三方资料库查看等品质/测试JMeterJMeter 是一种用于测试 Web 应用程序的负载测试工具。即便 JMeter 用于负载/性能测试,它依然能够用于启动 API 调用、状态代码和响应。JMeter 还反对很多插件。 ...

January 7, 2022 · 2 min · jiezi

关于devops:DevOps-运维实践经验实例

DevOps 实践经验以下列举了一些 DevOps 最佳实际: 继续集成继续交付微服务基础设施代码监控和日志记录沟通与单干继续集成-CI 采纳继续集成时,开发人员会定期将他们的代码变更合并到一个地方存储库中,之后零碎会主动运行构建和测试操作。继续集成的次要指标是更快发现并解决谬误,进步软件品质,并缩短验证和公布新软件更新所需的工夫。继续交付-CD 是通过继续交付零碎能够主动构建和测试代码更改,并为将其公布到生产环境做好筹备。继续交付能够在构建阶段后将所有代码变更都部署到测试环境和/或生产环境中,从而实现对继续集成的扩大。当继续交付得以正确施行时,开发人员将始终可能取得一个已通过标准化测试流程的部署就绪型构建工件。微服务 微服务架构是一种将单个应用程序构建为一系列小服务的设计办法。其中每个服务均按各自的流程运行,并利用一种轻型机制(通常为基于 HTTP 的应用程序编程接口 (API))通过一个明确定义的接口与其余服务进行通信。微服务围绕着业务能力进行构建,每项服务均限定到单个目标。您能够应用不同的框架或编程语言来编写微服务,并将其作为单个服务或一组服务进行独立部署。基础设施代码 通过代码和软件部署技术(例如版本控制和继续集成)得以预置和治理。开发人员和系统管理员可能以编程形式与基础设施进行大规模互动,而无需手动设置和配置资源。因而,工程师能够应用基于代码的工具来连贯基础设施,并且可能以解决利用程序代码的形式来解决基础设施。基础设施和服务器由代码进行定义,因而能够应用标准化模式进行疾速部署、应用最新补丁和版本进行更新,或者以可反复的形式进行复制。组织能够主动跟踪、验证和重新配置由代码形容的基础设施。配置管理 开发人员和系统管理员应用代码将操作系统和主机配置、操作性工作等自动化。代码的应用实现了配置变更的可重复性和标准化。它将开发人员和系统管理员从手动配置操作系统、零碎应用程序或服务器软件的工作中解放出来。监控和日志记录 组织对各项指标和日志进行监控,以理解应用程序和基础设施性能如何影响其产品的最终用户体验。通过对应用程序和基础设施生成的数据进行采集、分类和剖析,组织能够理解变更或更新如何影响用户,同时深刻理解呈现问题或意外变故的根本原因。因为服务必须全天候继续可用,而且应用程序和基础设施的更新频率一直进步,因而被动监控变得日益重要。此外,创立警报或对这些数据执行实时剖析也能帮忙组织更被动地监控其服务。沟通与单干 加强组织外部的沟通与单干是 DevOps 文化的一个重要方面。DevOps 工具的应用和软件交付流程的自动化可能以物理形式将开发和运行的工作流程及职责联合起来,从而建设团队之间的相互协作。在此基础上,这些团队建立了弱小的文化标准,提倡信息共享和通过聊天应用程序、问题或我的项目追踪零碎以及 Wikis 来促成沟通。这有助于放慢开发人员、经营团队甚至其余团队之间的沟通,从而使组织的各个部门围绕独特的指标和我的项目更严密地联合在一起。DevOps 工具 DevOps 模式依赖于无效的工具来帮忙团队疾速牢靠地部署并针对客户进行翻新。这些工具能够主动执行手动工作,帮忙团队大规模治理简单环境,并使工程师可能管制 DevOps 实现的高速度。 gitlab runner 流水线 CICD 实例形容当固定分支代码有提交触发编译,触发gitlab runner 编译代码并上传网盘或者服务器,部署到虚拟机须要手动触发。 gitlab-runner 部署及关联gitlab,能够参照下方帖子 https://segmentfault.com/a/11... .gitlab-ci.ymlbefore_script:    - echo "before script!"variables:    SCID: 'sc1765'    PGID: 'sc1765_82'    PG1_NAME: 'tkzjframe-conline-consumption'    PG1_PORT: '8080'    PG2_NAME: 'tkzjframe-conlineSys-consumption'    PG2_PORT: '8081'    PG3_NAME: 'tkzjframe-conline-core'    PG4_NAME: 'tkzjframe-conlineSys-core'    env1: 'pro'    IP_801: '10.130.105.121'    IP_802: '10.130.105.122'    tomcat_LIST: "${PG1_NAME} ${PG2_NAME}"    jar_LIST: "${PG3_NAME} ${PG4_NAME}"    IP_LIST: "${IP_801} ${IP_802}"    PASS_FILE: '/etc/rsync_user.password'    RS800_SERVER: '10.130.159.1'    RS500_SERVER: '10.154.140.130'stages:    - build    - deploy    - rollback    - restart    - logsbuild_job:    stage: build    script:        - pwd        - ip a        - pathpwd=`pwd`        - mvn clean install -Dmaven.test.skip=true -P${env1}        - echo $jar_LIST        - for i in ${jar_LIST};do cd ${pathpwd}/${i}/target;ls ; APPNAME=`ls -l *.jar | grep $i | grep -v original | head -n 1 | awk -F ' ' '{print $9}'`;mv $APPNAME ${i}-${env1}.jar; done        - ls -l        - for k in ${jar_LIST};do cd ${pathpwd}/${k}/target ;ls ; rsync -avz ${k}-${env1}.jar rsync_user@${RS800_SERVER}::rsync_server/${SCID}/ --password-file=${PASS_FILE} ;done        - echo $tomcat_LIST        #- for i in ${tomcat_LIST};do cd ${pathpwd}/${i}/target;ls ; APPNAME=`ls -l *.war | grep $i | head -n 1 | awk -F ' ' '{print $9}'`;mv $APPNAME ${i}.war; done        - ls -l        - for k in ${tomcat_LIST};do cd ${pathpwd}/${k}/target ;ls ; rsync -avz ${k}.war rsync_user@${RS800_SERVER}::rsync_server/${SCID}/ --password-file=${PASS_FILE} ;done    only:        - master    tags:        - prod-deploy-106.76deploy_tkzjframe-conline-consumption_tomcat1:    stage: deploy    script:        - for i in ${IP_LIST};do ssh appadmin@${i} "cd /home/appadmin/tomcat && wget -O update.sh http://mirrors.tkhealthcare.com/rsync_server/data/${SCID}/update.sh && sh +x update.sh -t tomcat -d ${PG1_PORT} -e ${env1} -s ${SCID} -p ${PG1_NAME} -a deploy"; done        #- ssh appadmin@${IP_801} "cd /home/appadmin/tomcat && wget -O update.sh http://mirrors.tkhealthcare.com/rsync_server/data/${SCID}/update.sh && sh -x update.sh -t tomcat -d ${PG1_PORT} -e ${env1} -s $SCID -p ${PG1_NAME} -a 'deploy'"    when: manual    only:        - master    tags:        - prod-deploy-106.76                        deploy_tkzjframe-conlineSys-consumption_tomcat2:    stage: deploy    script:        - for i in ${IP_LIST};do  ssh appadmin@${i} "cd /home/appadmin/tomcat && wget -O update.sh http://mirrors.tkhealthcare.com/rsync_server/data/${SCID}/update.sh  && sh +x update.sh -t tomcat -d ${PG2_PORT} -e ${env1} -s ${SCID} -p ${PG2_NAME} -a 'deploy'"; done    when: manual    only:        - master    tags:        - prod-deploy-106.76        deploy_tkzjframe-conline-core_jar1:    stage: deploy    script:        - for i in ${IP_LIST};do  ssh appadmin@${i} "cd /home/appadmin/tomcat && wget -O update.sh http://mirrors.tkhealthcare.com/rsync_server/data/${SCID}/update.sh && sh -x update.sh -s ${SCID} -e ${env1} -p ${PG3_NAME} -a 'deploy'"; done    when: manual    only:        - master    tags:        - prod-deploy-106.76deploy_tkzjframe-conlineSys-core_jar2:    stage: deploy    script:        - for i in ${IP_LIST};do  ssh appadmin@${i} "cd /home/appadmin/tomcat && wget -O update.sh http://mirrors.tkhealthcare.com/rsync_server/data/${SCID}/update.sh && sh +x update.sh -s ${SCID} -e ${env1} -p ${PG4_NAME} -a 'deploy'"; done    when: manual    only:        - master    tags:        - prod-deploy-106.76restart_tkzjframe-conline-consumption_tomcat1:    stage: restart    script:        - for i in ${IP_LIST};do  ssh appadmin@${i} "cd /home/appadmin/tomcat  && sh +x update.sh -d ${PG1_PORT} -t tomcat -e ${env1} -s ${SCID} -p ${PG1_NAME} -a 'restart'"; done    when: manual    only:        - master    tags:        - prod-deploy-106.76                        restart_tkzjframe-conlineSys-consumption_tomcat2:    stage: restart    script:        - for i in ${IP_LIST};do  ssh appadmin@${i} "cd /home/appadmin/tomcat && sh +x update.sh -d ${PG2_PORT} -t tomcat -e ${env1} -s ${SCID} -p ${PG2_NAME} -a 'restart'"; done    when: manual    only:        - master    tags:        - prod-deploy-106.76        restart_tkzjframe-conline-core_jar1:    stage: restart    script:        - for i in ${IP_LIST};do  ssh appadmin@${i} "cd /home/appadmin/tomcat && sh +x update.sh -s ${SCID} -e ${env1} -p ${PG3_NAME} -a 'restart'"; done    when: manual    only:        - master    tags:        - prod-deploy-106.76restart_tkzjframe-conlineSys-core_jar2:    stage: restart    script:        - for i in ${IP_LIST};do  ssh appadmin@${i} "cd /home/appadmin/tomcat && sh +x update.sh -s ${SCID} -e ${env1} -p ${PG4_NAME} -a 'restart'"; done    when: manual    only:        - master    tags:        - yly-prod-10.130.105.98rollback_tkzjframe-conline-consumption_tomcat1:    stage: rollback    script:        - for i in ${IP_LIST};do  ssh ${i} "cd /home/appadmin/tomcat && sh +x update.sh -t tomcat  -d ${PG1_PORT} -e ${env1} -s ${SCID} -p ${PG1_NAME} -a 'rollback'"; done    when: manual    only:        - master    tags:        - prod-deploy-106.76                        rollback_tkzjframe-conlineSys-consumption_tomcat2:    stage: rollback    script:        - for i in ${IP_LIST};do  ssh ${i} "cd /home/appadmin/tomcat && sh +x update.sh -t tomcat  -d ${PG2_PORT} -e ${env1} -s ${SCID} -p ${PG2_NAME} -a 'rollback'"; done    when: manual    only:        - master    tags:        - prod-deploy-106.76        rollback_tkzjframe-conline-core_jar1:    stage: rollback    script:        - for i in ${IP_LIST};do ssh ${i} "cd /home/appadmin/tomcat && sh +x update.sh -s ${SCID} -e ${env1} -p ${PG3_NAME} -a 'rollback'"; done    when: manual    only:        - master    tags:        - prod-deploy-106.76rollback_tkzjframe-conlineSys-core_jar2:    stage: rollback    script:        - for i in ${IP_LIST};do ssh ${i} "cd /home/appadmin/tomcat && sh +x update.sh -s ${SCID} -e ${env1} -p ${PG4_NAME} -a 'rollback'"; done    when: manual    only:        - master    tags:        - prod-deploy-106.76update.sh#!/bin/bash. /etc/rc.d/init.d/functions. /etc/profileprintUsage(){    echo "usage: update.sh -t <TYPE> -s <SCID> -d <PG_PORT> -p <PG_NAME> -e <ENVe> -a <action>"    exit -1}if [ $# -eq 0 ];then    printUsagefiwhile getopts :s:p:d:e:t:a: opts;do    case "$opts" in        t)            TYPE=$OPTARG            ;;        s)            SCID=$OPTARG            ;;        p)            PG_NAME=$OPTARG            ;;        d)            PG_PORT=$OPTARG            ;;        e)            ENVe=$OPTARG            ;;        a)            ACTOINS=$OPTARG            ;;        :)            echo "$0 must supply an argument to option -$OPTARG!"            printUsage            ;;        ?)            echo "invalid option -$OPTARG ignored!"            printUsage            ;;    esacdoneif [ -z "$SCID" ];then    printUsage    exit -1fiecho "$SCID:$PG_NAME:${ENVe}:${ACTOINS}:${PG_PORT}"shift $(($OPTIND-1));if [ $# -gt 0 ];then    echo "other arguments:$@";fiDATEtmp=$(date +%Y%m%d%H%M)DATE=$(date +%Y%m%d%H)PG_PID_LINE=$(ps aux | grep java | grep $PG_NAME | wc -l)PG_PATH="/home/appadmin/tomcat"NginxPG_PATH="/usr/local/openresty/nginx/html"PG_DOWN_URL="http://mirrors.tkhealthcare.com/rsync_server/data/${SCID}"backup() {    cd $PG_PATH    if [ -f ${PG_PATH}/${PG_NAME}.${DATE}.bak.jar ]; then        echo "Bakup files ${PG_NAME}.${DATE}.bak.jar has already."    else        mv ${PG_NAME}-${ENVe}.jar ${PG_PATH}/${PG_NAME}.${DATE}.bak.jar || echo "first time deploy-project"        action "Backup files is ok, bk_file is : ${PG_NAME}.${DATE}.bak.jar" /bin/true    fi}tomcat_backup() {    cd ${PG_PATH}/tomcat_${PG_PORT}/webapps/    if [ -f ${PG_NAME}.${DATE}.war.bak ]; then        echo "Bakup files ${PG_NAME}.${DATE}.war.bak has already."    else        mv ${PG_NAME}.war ${PG_PATH}/tomcat_${PG_PORT}/webapps/${PG_NAME}.${DATE}.war.bak || echo "first time deploy-project"        action "Backup files is ok, bk_file is : ${PG_NAME}.${DATE}.war.bak " /bin/true    fi}frontbackup() {    cd $NginxPG_PATH    if [ -d ${NginxPG_PATH}/${PG_NAME}.${DATE} ]; then        echo "Bakup files  has already."            else        mv ${NginxPG_PATH}/${PG_NAME}-${ENVe} ${NginxPG_PATH}/${PG_NAME}.${DATE} || echo "first time deploy-project"        action "Backup files is ok, bk_file is : ${PG_NAME}.${DATE}" /bin/true    fi}stopproject() {    if [ $PG_PID_LINE -eq 0 ]; then        echo "$PG_NAME is not running ."    else        ps aux | grep java | grep $PG_NAME | awk -F ' ' '{print $2}' | xargs kill -9         #cd ${PG_PATH} && sh +x ${PG_NAME}.sh stop        action "$PG_NAME stop ..." /bin/true    fi}tomcat_stopproject() {    echo "stop tomcat"    #${PG_PATH}/${PG_PORT}/bin/catalina.sh stop || (ps -ef | grep 8080 | awk '{print $2}'| xargs kill -9 )    (ps -ef | grep ${PG_PATH}/tomcat_${PG_PORT} | grep -v grep | grep -v catalina.sh |awk '{print $2}' | xargs kill -9) || echo "stop--- service is not running"}tomcat_startproject() {    sh +x ${PG_PATH}/tomcat_${PG_PORT}/bin/startup.sh}startproject() {    cd ${PG_PATH} && echo "nohup java -jar ${PG_NAME}-${ENVe}.jar ${ENVe} > ${PG_NAME}-${ENVe}.log &" > ${PG_NAME}_start.sh    sh +x ${PG_NAME}_start.sh    if [ -f ${PG_NAME}-${ENVe}.jar ]; then        cd         echo "$PG_NAME starting"    else        action "${PG_NAME}-${ENVe}.jar is no found." /bin/false        exit    fi}checkpg() {    sleep 15    new_pid_line=`ps aux | grep java | grep $PG_NAME | wc -l`    if [[ ${new_pid_line} -eq 0 ]]; then        echo "$PG_NAME 服务[过程]启动失败."            exit 777        else        echo "$PG_NAME 服务[过程]及[端口]启动胜利 . --OK"    fi}tomcat_checkpg() {    sleep 15    new_pid_line=$(netstat -tnlp | grep  $PG_PORT | wc -l)    if [ $new_pid_line -eq 0 ]; then        #kill -9 $new_pid        action "$PG_NAME 服务[端口]启动失败." /bin/false        exit 777    fi}checkend() {    sleep 30    new_pid_line=$(ps aux | grep java | grep $PG_NAME | wc -l)    new_pid=$(ps aux | grep java | grep $PG_NAME | awk -F ' ' '{print $2}')    port_wc=$(netstat -tunlp | grep $new_pid | wc -l)    if [ $port_wc -eq 0 ] && [ $new_pid_line -eq 1 ]; then        kill -9 $new_pid        action "$PG_NAME 服务[端口]启动失败." /bin/false        exit 777    fi}update() {    cd $PG_PATH    [ -f ${PG_NAME}-${ENVe}.jar ] && rm -rf ${PG_NAME}-${ENVe}.jar    wget -O ${PG_NAME}-${ENVe}.jar ${PG_DOWN_URL}/${PG_NAME}-${ENVe}.jar    ls -l ${PG_NAME}-${ENVe}.jar}tomcat_update() {    cd $PG_PATH/tomcat_${PG_PORT}/webapps/    [ -f ${PG_NAME}.war ] && rm -rf ${PG_NAME}.war    rm -rf ${PG_NAME} pwd  wget -qO ${PG_NAME}.war ${PG_DOWN_URL}/${PG_NAME}.war || echo "download war failed"    ls -l ${PG_NAME}.war}frontupdate() {    cd $NginxPG_PATH    [ -d ${PG_NAME}-${ENVe} ] && rm -rf ${PG_NAME}-${ENVe}    wget -O ${PG_NAME}-${ENVe}.tar.gz ${PG_DOWN_URL}/${PG_NAME}-${ENVe}.tar.gz    ls -l ${PG_NAME}-${ENVe}.tar.gz    tar -xf ${PG_NAME}-${ENVe}.tar.gz && mv dist ${PG_NAME}-${ENVe}}frontrollbackupdate() {    cd $NginxPG_PATH    [ -d ${PG_NAME}.${DATE} ] && mv ${PG_NAME}-${ENVe} /tmp/${PG_NAME}-${ENVe}.${DATEtmp}    cp -a ${PG_NAME}.${DATE} ${PG_NAME}-${ENVe}}tomcat_rollbackupdate() {    cd ${PG_PATH}/tomcat_${PG_PORT}/webapps/    [ -f ${PG_NAME}.${DATE}.war.bak ] || exit 777     rm -rf ${PG_NAME}.war ${PG_NAME}    cp -a ${PG_NAME}.${DATE}.war.bak ${PG_NAME}.war}rollbackupdate() {    cd ${PG_PATH}/    [ -f ${PG_NAME}.${DATE}.bak.jar ] || exit 777    mv ${PG_NAME}-${ENVe}.jar /tmp/${PG_NAME}-${ENVe}-${DATEtmp}.jar    cp -a ${PG_NAME}.${DATE}.bak.jar ${PG_NAME}-${ENVe}.jar}jenkinsupdate() {    cd $PG_PATH    [ -f ${PG_NAME}-${ENVe}.jar ] && rm -rf ${PG_NAME}-${ENVe}.jar    mv ../${PG_NAME}-${ENVe}.jar .    ls -l ${PG_NAME}-${ENVe}.jar}echo $ACTOINS if [ $ACTOINS == 'restart' ]; then    if [[ $TYPE == 'tomcat' ]]; then        tomcat_stopproject        tomcat_startproject        tomcat_checkpg    else        stopproject        startproject        checkpg    fielif [ $ACTOINS == 'stop' ]; then    stopproject    checkpgelif [ $ACTOINS == 'jenkins-deploy' ]; then    stopproject    backup    jenkinsupdate    startproject    checkpgelif [ $ACTOINS == 'deploy' ]; then    if [[ $TYPE == 'front' ]]; then        frontbackup        frontupdate    elif [[ $TYPE == 'tomcat' ]]; then        tomcat_backup        tomcat_stopproject        tomcat_update        tomcat_startproject        tomcat_checkpg        else        backup        stopproject        update        startproject        checkpg        fi        elif [ $ACTOINS == 'rollback' ]; then    if [ $TYPE == 'front' ]; then        frontrollbackupdate    elif [[ $TYPE == 'tomcat' ]]; then        tomcat_stopproject        tomcat_rollbackupdate        tomcat_startproject        tomcat_checkpg        else        stopproject        rollbackupdate        startproject        checkpg    fifi ...

January 6, 2022 · 14 min · jiezi

关于devops:加速服务农村最后一百米中和农信云原生DevOps转型之路

李楠,现任技术危险岗位负责人,负责中和农信SRE团队治理。主导信息化零碎的稳定性能力晋升,团队应急响应能力以及自动化运维平台效力建设,致力于DevOps转型和SRE能力落地。 马常炜,技术危险岗一号位,从业务运维到运维开发。先后承当屡次技术攻坚及推动技术演进:公有部署CICD落地到降级云原生效力平台云效研发平台应用、单体服务器高可用应用到Kubernetes集群部署、微服务网格化革新,自研自动化运维平台等。 背景中和农信,一家专一服务农村小微客户,应用数字技术来晋升服务效率的综合助农机构。主旨是为县域客群提供方便快捷、经济实惠、安全可靠的贴心服务,通过小额信贷、小额保险、农资电商、农品直采、技术培训等内容,助力他们倒退产业、增加收入,早日实现美好生活。 问题及痛点公司从小贷转型做综合助农服务后业务疾速的增长,IT员工从原来的70多人扩张到200多号人时,咱们发现公司原来应用自建的知识库(jira)+ 代码仓库(gitlab) + 构建工具(jenkins )的研发平台已不能满足现有研发生产: 咱们始终心愿能够无效改善这样一些问题: 组织规模和我的项目越来越大,怎么通过优化研发工具来晋升研发组织整体协同效率,感知每个团队的研发效力和项目风险;作为研发团队根底工具撑持,该怎么去一直优化工具来降本提效,让团队各个角色聚焦最有价值的中央,开释更多成员单位生产能力;在越来越多越简单服务研发过程中,怎么进一步整体晋升开发的品质和继续集成的效率,稳固生产的服务能力;解决方案云效--中和农信解决方案在考查和比照一些DevOps云工具之后,咱们抉择了阿里云的云效平台作为咱们研发治理的外围工具。 联合云效工具链和中和农信研发治理流程,咱们采纳了如下解决方案: 一、对立研发管理工具 为了晋升组织协同效率,咱们对立应用云效作为研发治理平台。 所有的我的项目成员信息对立从钉钉零碎中同步到各个子系统。 所有的我的项目需要,基于云效的项目管理工具进行对立治理。 基于云效的项目管理工具,按业务需要场景粒度建设我的项目。 基于我的项目对相干服务做需要、文档、迭代、工作、测试用例、代码、流水线的整体项目管理。 各个维度改良的前后 以及提效状况阐明: 二、降本增效的优化 开释SRE和其它角色继续集成配置方面投入,晋升性能上线交付效率。 基于流水线分组权限治理,治理不同环境。通过集成应用流水线API和流水线模板,标准化流水线生产,实现疾速生产流水线。 各个维度改良的前后 以及提效状况阐明: 三、晋升继续集成的品质和效率 具体形式有: 1、通过应用云效代码仓库,对代码规约、平安、敏感信息、代码评审进行治理,收敛共性的根底代码问题; 2、前置100%配置测试自动化验证流水线来晋升所有的服务根底上线品质; 各个维度改良的前后 以及提效状况阐明: 结语随着云和容器技术的倒退,DevOps和云原生的价值发现。咱们抉择阿里云的云效作为研发平台外围管理工具链,是它一站式的帮咱们解决了合作、编码、测试、交付、利用运维的研发全周期的根底效力治理平台,疾速结构了一个⾼效稳固的CI/CD零碎,让咱们初步实现了从传统研发模式往云原⽣DevOps转型。 以上内容是中和农信在施行应用云效后的成果,依靠云效解决了从传统研发模式往云原⽣DevOps的转型,疾速结构了一个⾼效稳固的CI/CD零碎,感激中和农信李楠&马常炜2位对云效的信赖和必定,心愿云效能够陪伴他们不断进步。 如果你也有故事要分享,请后盾留言分割咱们,一起打造10倍效力晋升案例集。 欢送大家应用云效,云原生时代新DevOps平台,通过云原生新技术和研发新模式,大幅晋升研发效率。现云效公共云根底版不限人数0元应用。 点击下方链接立刻体验云效DevOps全家桶! https://help.aliyun.com/docum... 对于咱们理解更多对于云效DevOps的最新动静,可微信搜寻关注【云效】公众号; 福利:公众号后盾回复【指南】,可取得《阿里巴巴DevOps实际指南》&《10倍研发效力晋升案例集》; 看完感觉对您有所帮忙别忘记点赞、珍藏和关注呦;

January 4, 2022 · 1 min · jiezi

关于devops:北纬科技三步走完成DevOps转型

分享人:任浩杰,北纬科技信息安全工程师,北纬科技云效迁徙DevOps的技术负责人。 背景北纬科技成立于1997年,是一家致力于提供挪动互联网先进产品和服务的挪动互联网服务集成商。晚期自主研发了公有PaaS平台(北纬利用引擎BWAE),起初因为公司转型及组织架构调整,逐渐用云效+ACR+ACK代替自研利用引擎,实现继续部署、交付、加重治理、保护及运维的压力。 问题及痛点为什么放弃自研,转而拥抱Saas服务? 晚期公司自研PaaS平台,历时较长。因PaaS平台本身的复杂性、技术倒退的多变性、零碎要求的稳定性的各类复合型要求,使平台无奈及时迭代更新满足各类场景需要,更好地为业务倒退服务。同时公司组织策略调整,人力资源重新分配,公司的自研平台面临比拟大的保护压力和运维压力。因而公司技术策略也随之调整,将自建机房及服务全副迁徙到阿里云上,同时调研腾讯、阿里、华为等商业化的DevOps平台,最终抉择阿里云云效作为DevOps继续部署的平台。 相比于自研,云效平台短少了企业的定制化、个性化,只能做到普适性,然而减少了平台的稳定性、健壮性、多样性,同时大大减少了人力、物力,加重了运维的压力。 解决成果应用云效后成果如下: 迁徙之路如何走?经验过近3个月的云效应用调研之后,公司启动云效迁徙我的项目,同时制订了以下三步走的迁徙策略。 第一步:外部试点、发现问题、解决问题。 第二步:积淀模版、梳理文档、标准流程。 第三步:全面迁徙、调配新资源、回收旧资源。 在迁徙中,对技术、老本、平安各方面进行一直优化。 1、技术优化 根底镜像优化: 因为每次构建Java镜像会导致镜像体积过大,OpenJDK官网的镜像大小为488MB,如果每次构建的镜像都这么大的话,对网络、存储等的影响及费用都会比拟大,因而咱们采纳离开构建的模式,根底镜像如JDK、PHP、GO、Nginx等镜像由运维人员保护,提供根底环境及k8s的主镜像。开发人员构建的镜像采纳busybox镜像,该镜像仅有根底的linux性能,因而只有1.23MB,该镜像只添加程序构建的产物如可执行文件、jar包或者html文件等,作为InitContainer容器,在启动时将构建产物复制到根底镜像中。该计划大大放大了docker镜像的大小和docker拉取镜像的网络开销。 流水线优化: 基于一次构建,屡次部署的思维,咱们将构建和部署流水线做了拆散,这样构建一次,开发、测试、生产能够屡次部署,且部署的版本能够不同。 定制化不同的流水线模板,依据不同事业部,不同业务需要模式、技术开发特定的要求,制订合乎各业务线的流水线模板。 不同的流水线模板 2、老本优化 通过了对企业应用部署的钻研,咱们在ACK集群上借助kubernetes提供的LimitRange的能力,对每一个命名空间做了一个根底容量的大小限度(CPU 0.5m,Memory 512Mi),而在利用的部署配置文件上为开发人员提供了设置cpu及memory的配置项,且提供了默认值。如果开发人员通过评估和开发环境、测试环境的验证,须要减少容量的,能够申请对该命名空间进步限度。一方面将一部分ops能力下放给developer,两一个方面,通过对资源的被动和被动调节,大大节俭了老本,升高了原来自研平台上任意配置资源的问题。 同时通过云效的maven服务、代码治理服务,代替了原有平台搭建的代码治理服务器、maven服务器。不仅升高硬件老本资源,同时也升高保护此类服务器的人力老本。 3、平安优化 代码品质优化:得益于云效的代码扫描流水线中的代码扫描及平安扫描的工作插件,咱们对于品质和平安的接入治理不便。 咱们在流水线模版中引入了代码扫描及平安扫描,同时在生产环境退出了人工卡点的流程,作为审核,保障扫描后果符合要求。 代码扫描后果及具体报告 代码平安: 借助于云效的代码治理,将公司所有代码进行对立治理,依据不同事业部,不同业务线对代码进行分层、分组治理,并对代码组权限进行严格控制,缩小代码作为公司重要资源泄露的危险。 同时通过云效提供的敏感信息扫描,及时发现硬编码等问题,进步代码平安品质。 代码库敏感信息检测 权限管制: 我司对权限及流程有着严格的要求及制度。云效对于不同的产品提供了不同维度的权限,满足了“起码权限”的准则。以流水线为例,依据不同不同场景设置管理员、技术负责人、运维人员、开发人员不同的角色,更细粒度低管控流水线的权限。 结语北纬科技的DevOps转型之路,经验了从PaaS到SaaS的倒退历程,也正应了软件倒退的过程。SaaS也正成为现如今软件倒退的趋势,当然任何事物都有本人的劣势及有余,咱们应该辩证的去对待问题,同时也要摸索适宜本身的解决方案。 以上内容是北纬科技在施行应用云效后的成果,心愿能给各位同行带来一点帮忙。感激北纬科技团队对云效的信赖和必定,心愿云效能够陪伴他们不断进步。 如果你也有故事要分享,请后盾留言分割咱们,一起打造10倍效力晋升案例集。 对于咱们理解更多对于云效DevOps的最新动静,可微信搜寻关注【云效】公众号; 彩蛋:公众号后盾回复【指南】,可取得《阿里巴巴DevOps实际指南》&《10倍研发效力晋升案例集》; 看完感觉对您有所帮忙别忘记点赞、珍藏和关注呦;

December 28, 2021 · 1 min · jiezi

关于devops:深度-从DevOps到BizDevOps-研发效能提升的系统方法

简介:研发效力晋升不知从何下手、一头雾水?阿里资深技术专家一文为你揭秘研发效力晋升的零碎办法 注:本文是对云栖大会何勉分享内容的整顿,稍有删减,点击文末下方链接观看残缺视 这几年“研发效力”始终是热词,很多组织都会启动研发效力晋升专项。我与其中的很多有过深刻的交换,他们中达成最终目标的并不多,常常是高调开始,草草收尾。为什么什会这样呢? 晋升研发效力,首先要弄清楚要解决的问题是什么,而后才是落地解决问题的实际办法。否则问题没定义分明,就很难有好的后果。 那晋升研发效力到底要解决什么问题? 我将晋升效力要解决的问题,演绎为3个效力不等式。 三个不等式揭秘研发效力的实质 第一个不等式,部分效率不等于高效交付? 这一点,大家应该会感同身受。当咱们去问各个部门或者集体时,都感觉他们很忙,效率很高。然而,咱们去问业务部门或用户,却是另外一回事,他们会埋怨产品研发响应慢、交付迟、品质也不好。 这就是组织外部视角的部分效率并不等于用户视角的高效交付。这个是晋升研发效力要面对的首要问题。解决它须要更无效的组织协同、更正当的交付模式,和更好的过程品质。 接下来的问题是,高效交付就够了吗?这就引出了第二个效力不等式。 第二不等式,高效交付能不等于继续高效 有的时候,为了高效的交付,咱们能够采取长期动作,比方把一群人关在一起,成立一个长期我的项目,这样沟通合作会更便捷,这可能会达成一时的高效。然而,如果不足长期品质思维,当咱们在做下一个我的项目,往往会发现问题,之前的代码和设计存在各种问题,比方可批改、可复用性很差,它们成为后续我的项目的负债而不是资产,长期的效率无奈维持。 如何从高效交付转变成继续的高效,这是研发效力要解决的第2个问题。它对咱们的工程和技术能力和实际都提出了要求。 第三个不等式,高效交付不等于业务胜利 产品交付的目标是反对业务倒退和业务翻新。咱们必须保障交付的货色,能解决用户问题,并构建可继续的商业模式,否则交付再多也没有意义。 明天,市场和用户的不确定继续减少,破解这一问题不容易。它须要整个组织可能聚焦用户问题,疾速交付和试错,并造成无效反馈调整的闭环。做到这三点能力让高效交付转化为业务胜利,这是晋升研发效力要解决的第三个外围问题。 咱们认为,研发效力晋升的实质就是要解化解下面的三个不等式,从而把组织内的部分效率转化为用户可感知的高效交付,并保障继续的高效和带来业务的胜利。最终实现:“继续地顺畅高质量交付无效的价值”。这是效力晋升的基本指标。 研发效力晋升实际体系明确问题是开始,解决它们须要零碎的实际办法。接下来,咱们分享这些实际办法,它是咱们对过来的实际的提炼和总结,并概括为这个图。 整个图分为三个模块: 左侧是合作和需要实际。左上方咱们称之为业务驱动需要的合作模式和产品导向的交互模式,下边是以终为始的需要剖析和设计。左侧这部分实际解决的是部分效率如何带来高效的交付。 右侧是工程与技术实际。右上方咱们称为畛域驱动的架构和实现,两头是标准化的工程基础设施,上面是利用为核心的继续交付,这部分实际解决的问题是如何让咱们高效交付带来继续。 两头这部分是翻新实际。它蕴含:如何高效摸索业务、如何继续疾速地实现业务交付,并造成无效的反馈和调整的闭环。翻新实际要解决的问题就是高效交付如何带来业务的胜利。 接下来,咱们一步步开展,看一下各局部的要害效力晋升实际。 合作和需要实际首先咱们来看合作需要实际。 在介绍合作之前,咱们须要弄清楚合作的上下文——也就是当咱们谈合作时,咱们在谈什么。 让咱们先从梳理需要交付的外在构造开始。 首先,产品交付都是源于指标,有可能是用户指标,如:更高效的实现某项工作;也有可能是业务指标,如:实现业务的增长,进步用户的黏性等。咱们基于用户指标和业务指标布局业务需要。除了业务指标外,客户的具体诉求也会转化为业务需要。 业务需要的实现须要落地到产品中,它会被合成为一个个的产品需要。产品需要会进一步被合成为技术工作,通过实现技术工作来交付产品需要,最终实现对应的业务需要。 当然,产品需要并不一定都间接来自业务需要,产品也会做出本人的布局,包含架构的降级和技术重构,或者面向未来的前瞻性技术布局,如AI算法、区块链平台等。这部分产品需要,尽管不来自当下的业务需要,但它同样服务于业务指标,只不过是长期和将来的业务指标。 理解了产品交付的构造之后,接下来,咱们看在这样的构造下,如何实现团队的高效协同。 业务驱动的合作模式 首先,咱们协同的构造应该和后面的产品交付需要层次结构统一。业务需要、产品需要和技术工作由不同的职能的人来负责,例如业务人员负责创立业务需要,业务人员和产品经理一起把业务需要布局合成为产品需要。 业务需要、产品需要、技术工作,这是交付需要过程中的根本价值单元。而文档、代码、测试、数据等都是为它们服务的,与应该向它们关联,并积淀为资产。 业务须要被收集、治理、布局和交付,实现这些工作须要有独立的空间,它对应研发协同工具中的“业务空间”。在业务空间中,还要能看到业务需要是如何拆分为产品需要的。咱们称之为管一层也要向下看一层,这样能力保障业务需要交付。 业务需要交付是一个动静的过程,须要清晰的工作流,它定义了业务需要从提出、接管、布局,直到公布、验收的整个过程。顺畅高质量地交付就是要让这个工作流更加顺畅,缩小过程中的妨碍和期待。 与业务需要一样,产品需要也须要被收集、治理、布局和交付,研发管理工具,同样要为产品人员提供专属的产品交付空间,并定义产品交付的工作流。技术开发者也须要对他们敌对的工作台。在这里,他们承受、治理、打算和实现技术工作。 更重要的是,咱们须要让这三个档次三者变成有机的整体,让大家真正的协同起来,顺畅的交付业务需要。这三个档次的工作流是互相关联,业务需要布局后被拆分为产品需要,产品需要会被进一步拆分为工作,这些是自上而下的。 再看自下而上的,上层的工作实现后,它的状态要可能被主动卷积下来,比方产品需要下所有的工作实现后,对应的产品需要进入待测试状态。业务需要所有产品需要实现后,业务需要的状态也须要主动变更。 这三个档次的联动和通明,让问题和妨碍更容易被辨认,比方业务需要交付延期或者呈现问题时,能清晰的看到是哪一个产品造成的,应该在哪里采取动作。 咱们把这称为业务驱动的合作模式。组织中不同的职能和团队,必须互相协同实现业务交付,达成用户或者业务的指标,业务驱动的合作模式,让这一过程更加通明和高效。 产品导向的交付模式后面讲的是合作模式,企业的业务需要最终还是要到落实到产品交付团队中交付的。以前咱们更多把IT交付团队看成老本核心,先确定需要范畴,再确定工夫,而后分配资源、成立我的项目、实现交付这也被称为我的项目导向的交付模式。 我的项目导向的交付实质是把人作为资源分配到事件上。其背地的假如是将来是确定的,在确定的工夫内交付确定的内容。它强调打算和执行,谋求交付的确定性。 确定性明天曾经越来越不事实,组织必须学会与变动共舞。另外,我的项目导向的交付导致短期思维,不足工程、技术长期改良意识。同时,因为团队的临时性,也无奈继续团队的交付效力。 数字化时代,咱们须要从我的项目导向的交付模式向产品导向的交付模式迁徙。产品导向的交付模式实质是把事件交给跨性能的个性团队,由绝对稳固的个性团队继续的承受并实现需要的交付。 个性团队对产品的迭代负责,他们拥抱业务的不确定性,并为此一直演进产品。个性团队要保护产品,必须建设长期思维,重视代码资产和工程资产,并继续改良团队交付能力和交付流程,晋升交付效力。 但这还不够,因为如果各个产品各自为政,任何个性团队的需要过载都会让它成为整个业务瓶颈,解决办法是,同一业务畛域的多个个性团队,共享同一需要列表。这就让一个团队呈现资源瓶颈时,需要能够调配到另一个团队,这与明天很多服务行业中履行的,“一个队列多个服务窗”的实质是统一的。 以终为始的需要剖析和设计后面,咱们讲了,企业的协同模式应该是业务驱动的,团队的交付模式应该是产品导向的,它们解决协同流程的问题,但光有流程是不够的,咱们还必须保障输出的品质。 IT行业有一句驰名的话:“输出的是垃圾,输入的也会是垃圾“ 。需要的输出,是交付过程是源头,也是最要害的局部。如果输出的有问题,交付的两头过程也不可能顺畅。那咱们应该怎么做呢? “输出垃圾,输入垃圾”的背面是以终为始,——也就是在需要输出的时候,团队要晓得最终要做成什么样子,并在业务、产品和技术之间达成统一。 那么,怎么才叫以终为始呢?以终为始分为3个方面: 第一,对于业务需要,要有明确的业务指标,并基于指标定义清晰的业务流程,确保业务流程能够反对业务指标的实现,这是业务剖析要实现的工作。 第二,对于产品需要,它要能反对业务流程的实现,为此咱们要基于业务流程,明确定义产品的性能,对于每一个产品性能,首先要明确用户应用的交互流程,并在交互流程的根底上,明确验收规范。 第三,明确业务需要、产品需要之间的构造,也就是业务需要和产品需要之间的层级关系。这对前面的团队合作都很重要,咱们合作交付的指标不是产品需要而是业务需要,只有构造清晰,合作的时才晓得这些产品需要如何协同向业务对齐,实现疾速交付业务需要。 总结一下,业务剖析和产品设计分是一个金字塔的构造: 需要永远源自业务指标,基于业务指标剖析业务流程,基于业务流程合成产品需要,并对产品需要进行设计。 金字塔的下面两层:是业务剖析关注的。咱们引入了“事件驱动的剖析”办法,——基于指标和业务事件剖析业务流程,并基于业务流程拆分定义产品需要,并划分最小可行产品(MVP)。 金字塔的上面两层:是产品设计所关注的。在业务流程设计的根底上,合成出产品需要,并对产品需要进行廓清。廓清和设计需要最好的形式是以用户应用实例来阐明操作流程、验收规定是什么样,也就是用户在什么状况下,做什么操作,将失去什么后果。咱们引入了“实例化需要”分析方法来反对这一过程。 通过零碎的业务剖析和产品设计办法,在需要上从GIGO转变为以终为始,这是部分效率转化为高效交付的重要一环。 ...

December 24, 2021 · 1 min · jiezi

关于devops:2021-年-25-大-DevOps-工具上

DevOps 正在扭转寰球软件开发的状态,DevOps 正以某种模式无效地进步进步寰球软件公司的上市速度、可销售性、翻新和产品质量。 2021 年是 DevOps 的重要一年。因为 DevOps 逾越开发、经营、IT、平安和产品团队等等,以及软件开发的不同阶段,因而有大量工具可供选择。 本文介绍目前市场上可用的一些顶级 DevOps 工具,同时牢记 CI/CD 生命周期的重要类别。本篇为配置管理、构建、源代码、部署工具,下篇次要是破绽治理、品质、监控、合作工具。 配置管理PuppetPuppet 是一种开源软件配置管理和部署工具,通常用于确保所有服务器都配置为所需的状态。Puppet 是基于代理的,最罕用于 Linux 和 Windows 同时管制多个应用程序服务器。Puppet 次要用于客户端/服务器配置,其中受管节点与服务器的配置放弃同步。借助 Puppet 的代码管理工具 R10K,能够更轻松地对 CI/CD 代码施行自动化或手动更改、更新、审查和测试。还能够应用 R10K 和 Puppetfiles 来主动部署环境。这些基于代理的部署个别比拟精确、及时,还能生成谬误日志以供审查。 Puppet 还为版本控制提供了与 Git 的简略集成。Puppet是申明式的,通常适宜基线而非编制。Puppet毛病: 总体速度迟缓在不编写自定义事实的状况下,Puppet 无奈查看 exec 资源之外的零碎状态Hiera是Puppet的键值配置数据查找零碎,速度慢且排查故障艰难AnsibleAnsible 是开源配置管理和编排工具,以其简洁和性能而闻名。Ansible 在主机上运行并应用 SSH 连贯到节点。Ansible 能够在任何装置了 Python 2(版本 2.7)或 Python 3(版本 3.5 及更高版本)的主机上运行,包含 Red Hat、Debian、CentOS、macOS 和 BSD。Ansible 让应用 YAML治理配置变得很容易。用 Ansible 做自动化跨平台工作也很无效。还能够应用 Ansible pull模式从特定文件中获取存储库和运行命令。将 Shell 脚本和配置文件转换为 Ansible Playbooks 或 Roles 也很容易,且有很多文档可用。 Ansible 毛病: ...

December 22, 2021 · 2 min · jiezi

关于devops:Flow-vs-Jenkins-实操对比如何将Java应用快速发布至ECS

简介:Jenkins 因为其开源个性以及丰盛插件能力,长久以来都是中小企业搭建 CICD 流程的首选。不过 Jenkins 存在保护老本高、配置简单等毛病,云效 Flow 较好地解决了这些问题。 本文从一个 Java 利用部署到云服务器(ECS)的场景切入,比照应用阿里云云效流水线 Flow 和 Jenkins 两种构建部署形式,供大家选型参考。 随着计算机技术和业务一直倒退,企业软件规模越来越宏大,交付越来越简单。继续交付 DevOps 解决方案逐步深入人心,成为企业开发者研发模式首选。 市面上存在多种多样的 CICD 工具,不同的工具有不同特点。从开源的本地工具 Jenkins、TeamCity,到云端收费工具 Travis CI、Github Action,到现在云原生时代专一于 Kubernetes 的 ArgoCD、Tekton Pipeline。 Jenkins 因为其开源个性以及丰盛插件能力,长久以来都是中小企业搭建 CICD 流程的首选。不过 Jenkins 存在保护老本高、配置简单等毛病,云效 Flow 较好地解决了这些问题。 本文从一个 Java 利用部署到云服务器(ECS)的场景切入,比照应用阿里云云效流水线 Flow 和 Jenkins 两种构建部署形式,供大家选型参考。 需要剖析以后咱们有一个寄存 Java 代码的仓库,须要对源代码进行构建,取得构建产物并将构建产物部署到云服务器(ECS)组。该过程简略形象如下: 以 Git 仓库 https://code.aliyun.com/flow-... Spring Boot 工程为例,须要有一个提供java、maven构建指令的运行环境进行 mvn build,将生成的 jar 包同步到服务器组上,执行利用启动命令(如 /home/admin/app/deploy.sh restart),将利用启动。 流程拆分环境筹备Flow Flow 作为一个 SaaS 服务,开箱即用。用户只须要一个阿里云账号即可开启继续交付之旅。 在Flow平台登陆阿里云账号后即可新建流水线 Jenkins Jenkins 是一个开源的 CI 工具,用户须要提供机器资源来部署 Jenkins Master 节点。如果须要在公网环境下拜访Jenkins页面,通过公网IP或弹性IP等裸露拜访地址。以一台阿里云 ECS(Centos 8)为例,装置Jenkins的过程包含: ...

December 21, 2021 · 2 min · jiezi

关于devops:从DevOps到BizDevOps-研发效能提升的系统方法

注:本文是对云栖大会何勉分享内容的整顿,稍有删减,点击文末下方链接观看残缺视 云效BizDevOps论坛:https://yunqi.aliyun.com/2021/agenda/session173 这几年“研发效力”始终是热词,很多组织都会启动研发效力晋升专项。我与其中的很多有过深刻的交换,他们中达成最终目标的并不多,常常是高调开始,草草收尾。为什么什会这样呢? 晋升研发效力,首先要弄清楚要解决的问题是什么,而后才是落地解决问题的实际办法。否则问题没定义分明,就很难有好的后果。 那晋升研发效力到底要解决什么问题? 我将晋升效力要解决的问题,演绎为3个效力不等式。 三个不等式揭秘研发效力的实质 第一个不等式,部分效率不等于高效交付? 这一点,大家应该会感同身受。当咱们去问各个部门或者集体时,都感觉他们很忙,效率很高。然而,咱们去问业务部门或用户,却是另外一回事,他们会埋怨产品研发响应慢、交付迟、品质也不好。 这就是组织外部视角的部分效率并不等于用户视角的高效交付。这个是晋升研发效力要面对的首要问题。解决它须要更无效的组织协同、更正当的交付模式,和更好的过程品质。 接下来的问题是,高效交付就够了吗?这就引出了第二个效力不等式。 第二不等式,高效交付能不等于继续高效 有的时候,为了高效的交付,咱们能够采取长期动作,比方把一群人关在一起,成立一个长期我的项目,这样沟通合作会更便捷,这可能会达成一时的高效。然而,如果不足长期品质思维,当咱们在做下一个我的项目,往往会发现问题,之前的代码和设计存在各种问题,比方可批改、可复用性很差,它们成为后续我的项目的负债而不是资产,长期的效率无奈维持。 如何从高效交付转变成继续的高效,这是研发效力要解决的第2个问题。它对咱们的工程和技术能力和实际都提出了要求。 第三个不等式,高效交付不等于业务胜利 产品交付的目标是反对业务倒退和业务翻新。咱们必须保障交付的货色,能解决用户问题,并构建可继续的商业模式,否则交付再多也没有意义。 明天,市场和用户的不确定继续减少,破解这一问题不容易。它须要整个组织可能聚焦用户问题,疾速交付和试错,并造成无效反馈调整的闭环。做到这三点能力让高效交付转化为业务胜利,这是晋升研发效力要解决的第三个外围问题。 咱们认为,研发效力晋升的实质就是要解化解下面的三个不等式,从而把组织内的部分效率转化为用户可感知的高效交付,并保障继续的高效和带来业务的胜利。最终实现:“继续地顺畅高质量交付无效的价值”。这是效力晋升的基本指标。 研发效力晋升实际体系明确问题是开始,解决它们须要零碎的实际办法。接下来,咱们分享这些实际办法,它是咱们对过来的实际的提炼和总结,并概括为这个图。 整个图分为三个模块: 左侧是合作和需要实际。 左上方咱们称之为业务驱动需要的合作模式和产品导向的交互模式,下边是以终为始的需要剖析和设计。左侧这部分实际解决的是部分效率如何带来高效的交付。 右侧是工程与技术实际。 右上方咱们称为畛域驱动的架构和实现,两头是标准化的工程基础设施,上面是利用为核心的继续交付,这部分实际解决的问题是如何让咱们高效交付带来继续。 两头这部分是翻新实际。 它蕴含:如何高效摸索业务、如何继续疾速地实现业务交付,并造成无效的反馈和调整的闭环。翻新实际要解决的问题就是高效交付如何带来业务的胜利。 接下来,咱们一步步开展,看一下各局部的要害效力晋升实际。 合作和需要实际首先咱们来看合作需要实际。 在介绍合作之前,咱们须要弄清楚合作的上下文——也就是当咱们谈合作时,咱们在谈什么。让咱们先从梳理需要交付的外在构造开始。 首先,产品交付都是源于指标,有可能是用户指标,如:更高效的实现某项工作;也有可能是业务指标,如:实现业务的增长,进步用户的黏性等。咱们基于用户指标和业务指标布局业务需要。除了业务指标外,客户的具体诉求也会转化为业务需要。 业务需要的实现须要落地到产品中,它会被合成为一个个的产品需要。产品需要会进一步被合成为技术工作,通过实现技术工作来交付产品需要,最终实现对应的业务需要。 当然,产品需要并不一定都间接来自业务需要,产品也会做出本人的布局,包含架构的降级和技术重构,或者面向未来的前瞻性技术布局,如AI算法、区块链平台等。这部分产品需要,尽管不来自当下的业务需要,但它同样服务于业务指标,只不过是长期和将来的业务指标。 理解了产品交付的构造之后,接下来,咱们看在这样的构造下,如何实现团队的高效协同。 业务驱动的合作模式 首先,咱们协同的构造应该和后面的产品交付需要层次结构统一。业务需要、产品需要和技术工作由不同的职能的人来负责,例如业务人员负责创立业务需要,业务人员和产品经理一起把业务需要布局合成为产品需要。 业务需要、产品需要、技术工作,这是交付需要过程中的根本价值单元。而文档、代码、测试、数据等都是为它们服务的,与应该向它们关联,并积淀为资产。 业务须要被收集、治理、布局和交付,实现这些工作须要有独立的空间,它对应研发协同工具中的“业务空间”。在业务空间中,还要能看到业务需要是如何拆分为产品需要的。咱们称之为管一层也要向下看一层,这样能力保障业务需要交付。 业务需要交付是一个动静的过程,须要清晰的工作流,它定义了业务需要从提出、接管、布局,直到公布、验收的整个过程。顺畅高质量地交付就是要让这个工作流更加顺畅,缩小过程中的妨碍和期待。 与业务需要一样,产品需要也须要被收集、治理、布局和交付,研发管理工具,同样要为产品人员提供专属的产品交付空间,并定义产品交付的工作流。技术开发者也须要对他们敌对的工作台。在这里,他们承受、治理、打算和实现技术工作。 更重要的是,咱们须要让这三个档次三者变成有机的整体,让大家真正的协同起来,顺畅的交付业务需要。这三个档次的工作流是互相关联,业务需要布局后被拆分为产品需要,产品需要会被进一步拆分为工作,这些是自上而下的。 再看自下而上的,上层的工作实现后,它的状态要可能被主动卷积下来,比方产品需要下所有的工作实现后,对应的产品需要进入待测试状态。业务需要所有产品需要实现后,业务需要的状态也须要主动变更。 这三个档次的联动和通明,让问题和妨碍更容易被辨认,比方业务需要交付延期或者呈现问题时,能清晰的看到是哪一个产品造成的,应该在哪里采取动作。 咱们把这称为业务驱动的合作模式。组织中不同的职能和团队,必须互相协同实现业务交付,达成用户或者业务的指标,业务驱动的合作模式,让这一过程更加通明和高效。 产品导向的交付模式 后面讲的是合作模式,企业的业务需要最终还是要到落实到产品交付团队中交付的。以前咱们更多把IT交付团队看成老本核心,先确定需要范畴,再确定工夫,而后分配资源、成立我的项目、实现交付这也被称为我的项目导向的交付模式。 我的项目导向的交付实质是把人作为资源分配到事件上。其背地的假如是将来是确定的,在确定的工夫内交付确定的内容。它强调打算和执行,谋求交付的确定性。 确定性明天曾经越来越不事实,组织必须学会与变动共舞。另外,我的项目导向的交付导致短期思维,不足工程、技术长期改良意识。同时,因为团队的临时性,也无奈继续团队的交付效力。 数字化时代,咱们须要从我的项目导向的交付模式向产品导向的交付模式迁徙。产品导向的交付模式实质是把事件交给跨性能的个性团队,由绝对稳固的个性团队继续的承受并实现需要的交付。 个性团队对产品的迭代负责,他们拥抱业务的不确定性,并为此一直演进产品。个性团队要保护产品,必须建设长期思维,重视代码资产和工程资产,并继续改良团队交付能力和交付流程,晋升交付效力。 但这还不够,因为如果各个产品各自为政,任何个性团队的需要过载都会让它成为整个业务瓶颈,解决办法是,同一业务畛域的多个个性团队,共享同一需要列表。这就让一个团队呈现资源瓶颈时,需要能够调配到另一个团队,这与明天很多服务行业中履行的,“一个队列多个服务窗”的实质是统一的。 以终为始的需要剖析和设计 后面,咱们讲了,企业的协同模式应该是业务驱动的,团队的交付模式应该是产品导向的,它们解决协同流程的问题,但光有流程是不够的,咱们还必须保障输出的品质。 IT行业有一句驰名的话:“输出的是垃圾,输入的也会是垃圾“ 。需要的输出,是交付过程是源头,也是最要害的局部。如果输出的有问题,交付的两头过程也不可能顺畅。那咱们应该怎么做呢?“输出垃圾,输入垃圾”的背面是以终为始,——也就是在需要输出的时候,团队要晓得最终要做成什么样子,并在业务、产品和技术之间达成统一。 那么,怎么才叫以终为始呢?以终为始分为3个方面: 第一,对于业务需要,要有明确的业务指标,并基于指标定义清晰的业务流程,确保业务流程能够反对业务指标的实现,这是业务剖析要实现的工作。 第二,对于产品需要,它要能反对业务流程的实现,为此咱们要基于业务流程,明确定义产品的性能,对于每一个产品性能,首先要明确用户应用的交互流程,并在交互流程的根底上,明确验收规范。 第三,明确业务需要、产品需要之间的构造,也就是业务需要和产品需要之间的层级关系。这对前面的团队合作都很重要,咱们合作交付的指标不是产品需要而是业务需要,只有构造清晰,合作的时才晓得这些产品需要如何协同向业务对齐,实现疾速交付业务需要。 总结一下,业务剖析和产品设计分是一个金字塔的构造: 需要永远源自业务指标,基于业务指标剖析业务流程,基于业务流程合成产品需要,并对产品需要进行设计。 ...

December 21, 2021 · 1 min · jiezi

关于devops:空余时间有兴趣一起做一个CICD的朋友可以联系我呀

我是一枚10年+Java程序员,想在Devops方面有更进一步的成长,所以想到做一个开源的Devops我的项目,大家一起做我的项目一起成长,寻找UI,运维相干的敌人。大家一起做,一起成长,在这个我的项目过程中能够让你入门Java并能独立实现后盾管理系统,你也让我入门你们的业余。如果有工夫有趣味,能够通过集体官网分割我:itproject-manager.comitproject-manager.com

December 19, 2021 · 1 min · jiezi

关于devops:大型前端项目-DevOps-沉思录-CI-篇

本文作者:成龙腾讯前端开发工程师,负责腾讯文档前端开发与研发效力晋升,AlloyTeam成员。导语本篇文章将着重探讨 DevOps 在继续集成阶段须要提供的能力,将对工作流的设计及流水线的优化思路做一个简要解说。DevOps 一词源于 Development 和 Operations 的组合,行将软件交付过程中开发与测试运维的环节通过工具链买通,并通过自动化的测试与监控,缩小团队的工夫损耗,更加高效稳固地交付制品。 随着腾讯文档的我的项目规模越来越大,性能个性与保护人员越来越多,个性交付频率与软件品质之间的矛盾日渐尖利,如何均衡两者成为了目前团队亟需关注的一个重点,于是,落地一个欠缺的 DevOps 工具链便被提上日程。 当咱们在议论 CI 时,咱们在议论什么CI(Continuous Integration),即继续集成,指频繁地(一天屡次)将代码集成到骨干的行为。 留神,这里既蕴含继续将代码集成到骨干的含意,也蕴含继续将源码生成可供理论应用的制品的过程。因而,咱们须要通过 CI,自动化地保障代码的品质,并对其构建产物转换生成可用制品供下一阶段调用。 因而,在 CI 阶段,咱们至多有如下阶段须要实现: 1. 动态代码查看这其中包含,ESLINT/TSLINT 动态语法查看,验证 git commit message 是否符合规范,提交文件是否有对应 owner 能够 review 等等。这些动态查看不须要编译过程,间接扫描源代码就能够实现。 2. 单元测试/集成测试/E2E 测试自动化测试这一环节是保障制品品质的要害。测试用例的覆盖率及用例品质间接决定了构建产物的品质,因而,全面且欠缺的测试用例也是实现继续交付的必备因素。 3. 编译并整顿产物在中小型我的项目中,这一步通常会被间接省略,间接将构建产物交由部署环节实现。但对于大型项目来说,屡次频繁的提交构建会产生数量宏大的构建产物,须要失去妥善的治理。产物到制品的建设咱们接下来会有具体解说。 利于集成的工作流设计在正式接入 CI 前,咱们须要布局好一种新的工作流,以适应我的项目切换为高频集成后可能带来的问题与难点。这里波及到的革新层面十分多,除了催促开发人员习惯的转变以及进行新流程的培训外,咱们次要关怀的是源码仓库的更新触发继续集成步骤的形式。 1. 流水线的组织模式咱们须要一个适合的组织模式来治理一条 CI 流水线该在什么阶段执行什么工作。 市面上有十分多的 CI 工具能够进行抉择,仔细观察就会发现,无论是 Drone 这样的新兴轻量的工具,亦或是老牌的 Jenkins 等,都原生或通过插件形式反对了这样一个个性:Configuration as Code,即应用配置文件治理流水线。 这样做的益处是相当大的。首先,它不再须要一个 web 页面专门用于流水线治理,这对于平台方来说无疑缩小了保护老本。其次对于应用方来说,将流水线配置集成在源码仓库中,享受与源码同步降级的形式,使得 CI 流程也能应用 git 的版本治理进行标准与审计溯源。 确立了流水线的组织模式后,咱们还须要思考版本的公布模式以及源码仓库的分支策略,这间接决定了咱们该以什么样的形式布局流水线进行代码集成。 2. 版本公布模式的取舍在《继续交付 2.0》一书中提到,版本公布模式有三要素:交付工夫、个性数量以及交付品质。 这三者是互相制衡的。在开发人力与资源绝对固定的状况下,咱们只能对其中的两个因素进行保障。 传统的我的项目制公布模式是就义了交付工夫,期待所有个性全副开发实现并经验残缺人工测试后才公布一次新版本。但这样会使得交付周期变长,并且因为个性数量较多,在开发过程中的不可控危险变高,可能会导致版本无奈按时交付。不合乎一个成熟的大型项目对于继续交付的要求。 对于继续集成的思维来说,当咱们的集成频率足够高,自动化测试足够成熟且稳固时,齐全能够不必一股脑地将个性全堆在一次公布中。每开发实现一个个性就主动进行测试,实现后合入期待公布。接下来只须要在特定的工夫周期节点主动将曾经稳固的期待中的个性公布进来即可。这对于公布频率越来越高,公布周期越来越短的古代大型项目中无疑是一个最优解。 3. 分支策略与大部分团队一样,咱们原有的开发模式也是分支开发,骨干公布的思维,分支策略采纳业界最成熟也是最欠缺的 Git-Flow 模式。 ...

December 3, 2021 · 2 min · jiezi

关于devops:深化生态合作博睿数据APM正式上架华为云严选商城

在深入与华为的单干过程中,博睿数据又迈出了松软的一步。 近日,博睿数据APM利用性能监控零碎和配套服务入驻华为云严选商城,企业用户可通过华为云严选商城间接下单购买选用博睿数据APM利用性能监控零碎和配套服务,为企业应用性能监控带来全新的体验和服务。 此举不仅意味着华为对博睿数据APM 产品的高度认可,同时也意味着单方的单干已深刻到产品、解决方案等全方位畛域。 弱小性能加持,博睿数据正式入驻华为云严选商城 相熟华为云严选商城的人,应该晓得严选商城进入门槛颇高。作为华为云市场中的严选商城,素有“云上精品市场”之称,致力于提供稳固牢靠、平安可信、可继续翻新的云服务。依据产品、品质等,制订对立规定,优中选优,精中取精,通过构筑严选的模式,汇聚业界精英,从源头把关品质。 其“优中选优,精当选精”的准则,更像是为企业划定的难以逾越的高标准界限。 从取得资格到上线严选商城成为华为的生态合作伙伴,须要通过多轮的申请、审核、检测、复核等系列流程,入选的商品即为精品,无疑代表着行业高标准。 博睿数据此次可能拿到华为云严选商城这张“通行证”,则得益于旗下APM 产品弱小的性能和场景适配。此外,博睿数据此前就通过了华为鲲鹏920测试认证,于底层实现了对国产根底软硬件环境的兼容,并且博睿数据也实现了与鸿蒙零碎的适配,在技术和服务上博得了华为的好评,也为此次的单干奠定了根底。 从性能上来看,博睿数据的APM 利用性能监控可实现以下四个性能: 利用拓扑可视化:反对基于服务、集群、Agent层面对业务进行统计分析,通过利用衰弱体系以及主动拓扑发现,辨认并展现实时数据流转以及业务场景流转。数据关联剖析:捕捉业务、容器、零碎环境数据,并将各局部数据进行关联统计,通过调用拓扑主动发现以及下钻剖析,定位连累主机、业务等。代码级调用追踪:用户可通过利用调用过程瀑布图查看该业务调用的每一个线程内设办法堆栈、调用关系、办法执行耗时、以及节点调用信息。无论是用户级代码还是底层零碎级代码,都可逐级逐条地对其进行性能剖析。智能告警:基于业务周期变化规律创立动静基线并利用于告警,缩小误报与漏报,让告警更贴近业务特点以及周期变动。基于以上性能,企业用户可依照理论IT零碎架构进行层级划分,通过拓扑图出现利用中的子系统、不同机房、负载平衡集群、繁多容器等业务性能体现。采纳B/S架构,软件装置繁难,通过在web界面进行展现与治理,应用门槛低且保护简略,进步运维人员的工作效率。 在场景方面,同样反对四个场景:1. 端到端可视化:全业务链主动拓扑,清晰展示前后端逻辑关系,概览零碎全局。2. 性能剖析:通过对利用、服务、集群、主机、申请直至代码,逐层下钻,逐层剖析,发 现影响性能的起因。3. 根因剖析:基于多维指标的相互影响与关联,发现导致问题的根本原因,实现问题的疾速定位。4. 智能告警:告警指标通过智能算法主动关联相干趋势和其余指标,帮助用户疾速剖析告警问题。 在华为云严选商城,别离提供APM利用性能监控、APM 利用性能监控套餐以及APM单个探针购买服务,企业用户可按需购买。 全面欠缺的配套服务让博睿数据怀才不遇 除了弱小的性能加持以及多样化的场景适配外,博睿数据在配套服务方面也有一套残缺的流程。 在华为云严选商城,企业用户在选购服务时,博睿数据的APM 产品可依据客户的要求及工夫,提供近程及现场演示产品,近程次要以视频模式,公司外部有业余近程视频工具,可进行实时视频对话、零碎演示、语音解说等。也能够提供现场演示针对客户感兴趣的点和模块,进行现场零碎实操、答疑、PPT解说、案例解说等。 另外,博睿数据还为此建设了培训考核制度,培训考核制度是保障培训品质的一种伎俩。培训完结后,施行经理将对加入培训的人员进行考核,通过培训成果的量化,获取培训成果。施行经理剖析考核后果与培训成果反馈表,总结培训中现出的问题,及时解决改良,争取达到百分之百的成果。 此外,在博睿数据的APM利用性能监控零碎和配套服务入驻华为云严选商城之前,博睿数据的睿思众淘也曾经在华为利用市场上线。 让每一家企业享受IT经营数据的价值 此次,博睿数据APM利用性能监控零碎和配套服务胜利入选华为云严选商城,标记着博睿数据与华为的单干再次迈向了新的台阶,同时也是华为对于博睿数据的高度认可,单方在此前单干的根底上,进一步欠缺了供需对接,一方面博睿数据可充分发挥华为云严选的品牌及渠道劣势,另一方面华为云也可借博睿数据的产品拓展更多行业用户,造成优势互补。 华为云云市场生态单干总监张伟就示意:“博睿数据APM利用性能监控零碎和配套服务入驻华为云严选商城是单方在生态单干上积极探索、优势互补,打造以用户为核心的全新IT指标体系的重要动作,可能为企业提供更好的利用性能监控体验的同时,进一步晋升企业数字化转型过程中用户体验的晋升。” 博睿数据深圳区销售总监温剑也示意:“博睿数据APM利用性能监控零碎通过了华为云的严格的性能和平安测试,入驻华为云利用商城,并取得了严选认证,为下一步单方在利用性能监控畛域的联结市场拓展埋下了伏笔,也为下一步DEM用户数据体验监控上架华为云利用商城打下了松软的根底。” 作为华为云的优质合作伙伴,今后,博睿数据将与华为云携手共进,助力更多企业进行利用性能的监控,晋升用户满意度和整体竞争力,助力企业业务倒退,致力于让每一家企业都能享受IT经营数据的价值。

December 2, 2021 · 1 min · jiezi

关于devops:阿里巴巴服务网格技术三位一体战略背后的思考与实践

简介:本文分享了阿里巴巴服务网格技术三位一体策略背地的思考和实际,对于阿里云服务网格 ASM 的一些产品性能,包含最近公布的一些性能。 作者:宗泉、宇曾 阿里巴巴三位一体策略阿里云外部很早就提出了开源、自研、商业化三位一体策略,先谈谈我对它的了解。 多年的软件开发教训通知咱们,开发出一款杰出的软件有一些要害因素: 沟通反馈实际在软件开发过程中咱们不能闭门造车,不能随便“发明”业务场景需要。业务场景和产品性能须要提炼,开源给咱们提供了一个独特翻新的平台,基于这个平台,大家能够独特定义一些标准和规范。不同的厂商遵循相应的规范,客户就没有被锁定的危险,能够不停地迁徙,总是能找到最好的厂商,将本人的业务放上去,用最简略、最便捷、最经济的形式来经营本人的业务。 很多客户在抉择阿里云服务网格的时候,有一条比拟重要的评判指标:是否和社区 Istio 兼容。因为客户放心被锁定,强依赖于阿里云; 而后说到自研,兴许有同学会问到,开源与自研是否互相矛盾,答案是否定的。 因为,咱们这里提到的自研,其实是基于开源的自研,并非摒弃开源的版本,从新造个新的轮子。自研是指咱们要对开源产品有足够深度的了解: 要把握所有源代码;领有批改每一行代码的能力当然,自研还有意味着可能有本身业务特定独有的需要场景,一些没方法标准化的场景。基于自研,对开源产品的深度把控和了解,咱们将有通用客户场景需要的性能搬到云上,封装成云产品,让云上客户能够开箱即用去应用,这是商业化的初心。 回到阿里团体外部,开源、自研、商业其实是一个技术飞轮。 对于阿里的技术同学来说,每年的 双11 都是一场“盛宴”。为了让顾客有顺滑的购物体验,给商户提供更多样化的让利流动,阿里电商平台对于效率、可靠性、规模性的要求在 双11 的驱动下成倍进步,激发着技术人的后劲。作为根底技术外围之一,阿里巴巴中间件也会在每年 双11 迎来一次技术的全面演进和降级。 阿里在开源社区中推出了 Dubbo、RocketMQ、Nacos、Seata 等多个为人熟知的开源我的项目,激励宽广开发者共建中间件生态体系,也包含了 ServiceMesh 相干技术。 拥抱服务网格开源技术 阿里云外部很早就开始调研并实际 ServiceMesh 技术 。2018 年,Istio 正式公布 1.0 版本,进入公众视线。在这更早期间,阿里巴巴外部曾经开始参加相干生态开源产品的奉献。 阿里云在微服务生态畛域,也有一些开源的服务化框架,比方 Dubbo 、Spring Cloud Alibaba,能够说微服务畛域,因为电商这层试验大平台,阿里云在这方面是妥妥滴“技术专家”,咱们会进行横向性能比照,比照 Sidecar 模式和原有模式的优缺点;在这过程中,咱们也积极参与 Istio 微服务相干生态我的项目的开源奉献;例如 Envoy、 Dubbo Filter 、RocketMQ Filter 、Nacos Mcp 性能、Spring Cloud Alibaba、Sentinel 等。 目前风行着各种各样的服务框架,如何基于不同的框架开发的可互通的业务?服务框架就像铁路的铁轨一样,是互通的根底,只有解决了服务框架的互通,才有可能实现更高层的业务互通,所以用雷同的规范对立,合二为一并共建新一代的服务框架是必然趋势。 Dubbo 和 HSF 都是阿里巴巴外部在应用的微服务 RPC 框架。这些框架在阿里业务一直迭代开发的过程提供了松软的底层微服务能力反对,保障了一个又一个 双11 大促。 随同着云原生的浪潮,以及整体资源老本优化、DevOps 等大背景下,原有微服务框架 Dubbo 、HSF 的一些毛病也在缓缓裸露进去,比方多语言的反对,配置和代码逻辑拆散等,SDK 版本升级须要推动业务方,收买的业务采纳不同框架互通的问题等。 ...

December 2, 2021 · 3 min · jiezi

关于devops:函数计算-GB-镜像秒级启动下一代软硬件架构协同优化揭秘

简介:本文将介绍借助函数计算下一代 IaaS 底座神龙裸金属和平安容器,进一步升高相对提早且可能大幅升高冷启动频率。 作者:修踪 背景函数计算在 2020 年 8 月翻新地提供了容器镜像的函数部署形式。AWS Lambda 在 2020 年 12 月 Re-Invent,国内其余 FaaS 提供商在 2021 年 6 月也相继发表了 FaaS 反对容器的重磅性能。冷启动始终都是 FaaS 的痛点,引入比代码压缩包大几十倍的容器镜像后冷启动好转便成为开发者最大的担心。 函数计算在反对容器镜像的设计阶段就决定要让开发者像应用代码包(秒级弹性能力)一样的体验应用镜像,既要易用性也要放弃 FaaS 本身的极致弹性,罢黜用户的纠结和取舍。现实的用户体验是函数调用简直感觉不到镜像数据近程传输带来的提早额定耗费。 优化镜像减速冷启动大抵分为两种做法:升高相对提早和升高冷启动概率。自容器镜像上线以来咱们曾经通过镜像减速技术,分阶段升高了相对提早。本文在此基础上,介绍借助函数计算下一代 IaaS 底座神龙裸金属和平安容器,进一步升高相对提早且可能大幅升高冷启动频率。 优化历程(以某一镜像为例) 第一代架构:ECS 虚构机第一阶段(2021 年 3 月):按需加载,缩小数据传输 过来的问题在于启动镜像前全量拉取镜像外部数据,导致无用的镜像数据也会被残缺下载而占用了过多的筹备工夫。于是咱们最后的优化方向是尽量疏忽无用的镜像数据,达到按需加载。为此,咱们通过镜像减速技术,省略掉了拉取无用数据的工夫,实现了函数计算自定义镜像冷启动从分钟级到秒级晋升的相干技术细节。 第二阶段(2021 年 6 月):记录容器实例启动 I/O 轨迹,在后续实例启动中提前预取镜像数据 咱们发现,函数实例在容器启动和初始化阶段,I/O 数据拜访模式高度一致。依据 FaaS 平台基于利用运行模式调度资源的特点,咱们在函数实例首次启动时记录了 I/O 轨迹的脱敏数据,在后续的实例启动时,将轨迹数据作为提醒,提前预取镜像数据到本地,进一步减小了冷启动延时。 上述两种减速优化尽管大幅减小了冷启动相对提早,但因为传统 ECS VM 在闲置一段时间后就会被回收,再次启动新机器时就会从新触发冷启动。于是,如何缩小冷启动频次便成为了下一阶段重点攻克的题目之一。 下一代架构:弹性裸金属服务器(神龙)+microVM 在设计下一代架构时咱们不仅思考解决冷启动频次问题,也同样留神到缓存对于启动时延的影响。于是咱们创新性的创造了 Serverless Caching,依据不同的存储服务特点构建数据驱动、智能高效的缓存体系,实现软硬件协同优化,将 Custom Container 体验进一步晋升。函数计算后盾神龙的更迭工夫远大于 ECS VM 的闲置回收工夫,对于用户侧而言,热启动频率大幅晋升,在冷启动后,缓存会继续保留在神龙机器上,缓存命中率可达 90% 以上。 比照 ECS 虚拟机,神龙裸金属加上微型虚拟机的架构为镜像减速带来了更多的优化空间: ...

November 29, 2021 · 1 min · jiezi

关于devops:研发效能数据平台-DevLake-正式开源连接-DevOps-中的数据孤岛

建设研发工具链后,效力晋升如何更进一步? 工程师们反馈流程体验的确有所晋升,和业务共事的沟通仿佛也欢快了一些——但研发团队仍然须要量化数据作为抓手,一方面佐证先前实际优化的有效性,另一方面为继续的效力晋升寻找机会。 这并不容易。 首先,效力数据经常散落在软件研发生命周期的不同阶段、不同工作流、不同工具中,难以留存、会集并转化为无效洞见。其次,可能存在效力指标定义与计算方法含糊,难以获得团队认同。最初,如果数据只停留在数字,无奈依据研发治理具体场景的需要进行剖析与展示,也难以为研发团队发明价值。 11 月 17 日公布 0.4.0 版本的 DevLake 是一款面向以上问题的开源解决方案。 什么是 DevLakeDevLake(GitHub,Gitee)是开源的研发效力数据平台。它提供了自动化、一站式的数据集成、剖析以及可视化能力,帮忙研发团队疾速构建效力数据面板,开掘要害瓶颈与提效机会。 灵便、可扩大的数据接入能力针对 DevOps 工具链简单、数据散乱难以收集的问题,DevLake 从两方面进行设计提供接入能力。 一是反对数据指标的多样性:需要-设计-开发-测试-交付-经营指六个实际域的效力指标归于一处,连通软件研发全生命周期,由价值流动效率串联各环节的资源效率,防止效率竖井和局部优化。 二是反对数据源的多样性:同类工具共用形象层,数据格式及统计办法标准化,灵便整合不同DevOps工具数据;架构和插件设计灵便,不便用户二次开发,接入本人的数据源进行剖析。 以后 DevLake 反对接入支流工具 JIRA、GitHub、GitLab 及 Jenkins。用户也能够参考文档,奉献数据源插件。 内置效力指标与剖析能力针对效力指标定义与计算方法含糊的问题,DevLake 内置了一套研发效力指标体系,用户无需手动配置简单的计算剖析门路,即开即用。 目前 DevLake 反对20+常见研发效力指标: 利用于效力治理的不同维度DevLake 内置度量剖析能力,如趋势剖析、依照成员/阶段下钻剖析等,帮忙用户在不同场景下解读指标,取得无效洞见。 此外,DevLake也涵盖了细粒度剖析与根因回顾的实际倡议,疏导用户层层推动,定位关键问题,并建设可落地的改良措施。 DevLake 基于 Grafana 实现了数据可视化,反对自定义 SQL 查问和拖拽搭建数据面板。用户能够依据理论需要,自在搭建研发效力数据驾驶舱。 如何开始DevLake 目前提供两种部署形式: 基于 Docker 在本地部署,10 分钟疾速搭建启动,详细信息请参见文档基于疾速 POC 平台 Tin 在云端部署,点击链接一键开启试用疾速体验,详细信息请参见文档如果您有任何倡议或疑难,能够退出 Discord(英文) 或 或 飞书(中文)群组,与 DevLake 开发者沟通。

November 29, 2021 · 1 min · jiezi

关于devops:Rover-Terraform执行计划可视化工具

之前咱们通过一篇文章入门了应用Terrafrom以申明式配置文件(可版本化的代码)来创立和治理基础设施资源。 在应用命令terraform apply之前,咱们通常应用terraform plan来查看执行打算,输入的执行打算以相似“git diff”的文本形式形容。这里咱们将介绍如何以图形可是化的形式来理解执行打算。 Terrafrom Graph首先Terraform CLI工具自带了一个子命令 - graph,graph命令用于生产配置和执行打算的图形示意,其输入是DOT格局,能够通过Graphviz转化为图片,例如在Linux终端下 ❯ terraform graph | dot -Tsvg > graph.svg 对于简略的我的项目(治理的资源对象比拟的状况),咱们能够通过这个图形理解资源对象的关系。然而如果一个项目管理了大量的资源对象,应用graph生成的图形会显得错中简单,而且图形文件也比拟宏大。 那接下咱们将介绍一款开源的可视化工具。 RoverRover是一款开源的,可交互的Terraform配置和执行打算可视化工具,其通过Web服务的形式,是咱们能够通过浏览器查看生成的图形,并进行一些交互操作。 应用Rover非常容易,能够从其Github我的项目的Release下载为各平台编译好的二进制文件(命令)来运行,也能够通过Docker容器的形式运行。 如果应用下载的二进制文件,将下载好的二进制文件(例如 rover_v0.2.2)放到PATH门路下,例如 /usr/local/bin/rover,接下來在Terraform我的项目的文件夹下执行 ❯ rover2021/11/26 16:59:34 Starting Rover...2021/11/26 16:59:34 Initializing Terraform...2021/11/26 16:59:35 Generating plan...2021/11/26 16:59:37 Parsing configuration...2021/11/26 16:59:37 Generating resource overview...2021/11/26 16:59:37 Generating resource map...2021/11/26 16:59:37 Generating resource graph...2021/11/26 16:59:37 Done generating assets.2021/11/26 16:59:37 Rover is running on 0.0.0.0:9000运行rover命令,其将会执行以下操作 解析目录下的配置文件,并通过Terraform plan生成执行打算文件解析打算和配置文件,生成3种对象: 资源概览(rso),资源映射图(map),资源图(graph)应用下面的3中对象,将其转换为可交互的配置和状态视图,以Web服务器运行在本地的 9000 端口咱们能够通过浏览器拜访 http://localhost:9000/ 来查看可视化的后果。 整个页面蕴含4个局部 ...

November 27, 2021 · 1 min · jiezi

关于devops:零基础玩转SLS日志查询SLS-Query-Builder发布

简介:日志服务(Log Service,简称 SLS) 是阿里云提供的行业当先的日志大数据解决方案,一站式提供数据收集、荡涤、剖析、可视化、告警等性能。智能查问剖析是数据中台重要的一环,SLS反对秒级查问10亿到千亿级别的日志数据,为万级开发者提供每日百亿级的查问服务。SLS查问语句是日志服务的专有语法,为了帮忙用户简略、疾速地构建查问语句,升高用户的学习老本,SLS推出了查问辅助输入(Query Builder)性能,让用户无需关注语法细节也可实现查问。 背景日志服务(SLS)日志服务(Log Service,简称 SLS) 是阿里云提供的行业当先的日志大数据解决方案,一站式提供数据收集、荡涤、剖析、可视化、告警等性能,全面晋升海量日志解决能力,实时开掘数据价值,智能助力研发/运维/经营/平安等场景。 智能查问剖析是数据中台重要的一环,SLS反对秒级查问10亿到千亿级别的日志数据,为万级开发者提供每日百亿级的查问服务。SLS非常适合于做监控报表/告警/经营摸索式交互剖析,更能够通过API调用集成数据分析能力,集成到第三方的可视化平台,BI工具,或自研程序。 SLS查问剖析SLS的日志查问分为两局部:查问语句和剖析语句。查问语句和剖析语句以竖线(|)宰割,查问语句的语法为日志服务专有语法,剖析语句采纳规范的SQL92语法。 查问语句|剖析语句 其中,查问语句可独自应用,剖析语句必须与查问语句一起应用。即剖析性能是基于查问后果或全量数据进行的。 示例: // 仅查问status > 200// 仅统计* | SELECT status, count(*) AS PV GROUP BY status// 查问 + 统计status > 200 | SELECT status, count(*) AS PV GROUP BY statusQuery Builder介绍SLS查问语句是日志服务的专有语法,为了帮忙用户简略、疾速地构建查问语句,升高用户的学习老本,SLS推出了查问辅助输入(Query Builder)性能,让用户无需关注语法细节也可实现查问。 (注:以后版本只反对查问语句,SQL剖析语句的辅助输入性能SQL Builder将在后续版本推出,敬请期待) 1. 性能入口登录日志服务控制台,在Project列表区域,点击进入指标Project。在日志存储 > 日志库页签中,点击进入指标Logstore,在查问和剖析语句输入框中,点击右侧图标,唤起Query Builder面板。随后在配置查问条件面板中,配置查问条件即可。 2. 应用模式简洁模式简洁模式中的多个查问条件是平铺展现的,各个查问条件之间为同级关系。 高级模式高级模式中的多个查问条件是换行展现的,各个查问条件之间可设置层级关系,即对应于查问语句中的括号运算符。用户能够通过点击且、或两侧的<图标或>图标,定义各个查问条件之间的层级关系。 双向同步为了最大水平的保障用户应用的灵活性,Query Builder的查问条件与用户手动输出的查问语句是实时双向同步的。用户既能够通过Query Builder生成查问语句,也能够在查问框中批改生成的查问语句。Query Builder会实时解析用户手动输出的查问语句并同步到面板上。 3. 性能概述3.1 查问类型 全文查问和字段查问 ...

November 25, 2021 · 1 min · jiezi

关于devops:Terraform初探迁移本地项目到Terraform-Cloud执行

上一篇文章咱们尝试了在本地环境应用Terraform来创立和治理AWS Lightsail资源,对于治理一些云资源,咱们须要在本地装置相应的CLI工具和配置拜访相应云资源的凭据(例如AWS CLI, AccessKeyID等),Terraform通过调用本地的CLI工具或者云API来治理云资源的状态,其默认应用的是local类型的Backend,资源的状态文件(.tfstate)也是保留在本地文件目录中的。 这篇文章咱们将尝试应用remote类型的Backend,将我的项目迁徙到Terraform Cloud去执行,并且由Terraform Cloud来治理资源状态。 什么是Terraform CloudTerraform Cloud 是一个治理Terraform在统一且牢靠的环境中运行的SaaS利用,从而能够替换在本地机器是执行Terraform我的项目,其存储共享的状态和秘密数据,并能够连贯到版本控制系统(如 Git),使得咱们能够在团队中将基础设施作为代码进行工作。 Terraform是一个商业利用,团队和商业应用将会收取费用并提供了更多的高级性能。但对于个人用户,能够收费应用根本的性能。对于费用和性能详情,能够参考 (https://www.hashicorp.com/pro...)。 首先咱们须要注册一个Terraform Cloud的账号,拜访 https://app.terraform.io/sign... ,依据提醒注册要给收费的账号 注册实现后第一次登陆Terraform Cloud,其会询问如何开始一个我的项目,这里咱们抉择 Start from scratch,也就是将从一个空模板开始 接下来咱们须要创立一个组织(Organization),例如这里我创立一个名为 learn-terraform 的组织,一个组织就相似要给命名空间,能够治理多个工作空间(Workspace),还能够治理其下工作空间共享的变量和环境变量。 接下来咱们须要在本地环境登录Terraform Cloud,并增加相应的配置来从新初始化我的项目。 从新初始我的项目实现了Terraform Cloud的账号注册之后,咱们须要在本地终端运行 terraform login ,会关上浏览器来登录账号失去一个Token值,将其复制填入终端实现登录 > terrafrom loginTerraform must now open a web browser to the tokens page for app.terraform.io.If a browser does not open this automatically, open the following URL to proceed: https://app.terraform.io/app/settings/tokens?source=terraform-login---------------------------------------------------------------------------------Generate a token using your browser, and copy-paste it into this prompt.Terraform will store the token in plain text in the following filefor use by subsequent commands: /home/mengz/.terraform.d/credentials.tfrc.jsonToken for app.terraform.io: Enter a value:接着咱们批改我的项目的配置文件 main.tf ,退出 backend "remote" ...

November 25, 2021 · 2 min · jiezi

关于devops:Kubernetes-已经成为云原生时代的安卓这就够了吗

简介:本文将介绍如何在 Kubernetes 上构建新的利用治理平台,提供一层形象以封装底层逻辑,只出现用户关怀的接口,使用户能够只关注本人的业务逻辑,治理利用更快更平安。 作者:司徒放 导语:云原生时代,间接应用 Kubernetes 和云基础设施过于简单,如用户须要学习很多底层细节、利用治理的上手老本高、容易出错、故障频频。随着云计算的遍及,不同云又有不同的细节,进一步加剧了上述问题。 本文将介绍如何在 Kubernetes 上构建新的利用治理平台,提供一层形象以封装底层逻辑,只出现用户关怀的接口,使用户能够只关注本人的业务逻辑,治理利用更快更平安。 云原生时代是一个十分好的时代,咱们所面临的是整体技术的颠覆性变革,全面地对利用做端到端重构。目前,云原生在演进过程中产生了三个关键技术: 一是容器化,容器作为标准化交互的介质,在运维效率、部署密度和资源隔离性方面相比传统形式有很大改良,据 CNCF 最新调研报告显示,目前已有 92% 的企业生产零碎在应用容器; 二是 Kubernetes,它对基础设施进行了形象和治理,现已成为云原生的标配; 三是 Operator 自动化运维,通过控制器和定制资源的机制,使 Kubernetes 不仅能够运维无状态利用,还能够执行由用户定义的运维能力,实现更简单的自动化运维利用进行自动化部署和交互。 这三项关键技术其实是逐步演进的关系,另外,在利用交付畛域,也有与之对应的实践在追随上述技术一直地演进。云原生的崛起,带来了交付介质、基础设施治理、运维模型和继续交付实践的全面降级和冲破,减速了云计算时代的到来。 图 1 云原生技术全景图 从 CNCF 公布的云原生技术全景图(见图 1)中,能够看到云原生的蓬勃生态,细数图中这 900 + Logo,其中不乏开源我的项目、守业公司,将来云原生的技术都会在这些中央诞生。 云原生 “操作系统” Kubernetes带来的利用交付挑战上文提到,Kubernetes 已成为云原生的标配,其对下封装基础设施的差别,对上反对各种利用的运维部署,如无状态利用、微服务,再如有状态、批处理、大数据、AI、区块链等新技术的利用,在 Kubernetes 下面都有方法部署。Kubernetes 曾经成为了现实意义的 “操作系统” 。它在云原生的位置正如挪动设施中的 Android。为什么这样讲?Android 不仅仅装在咱们的手机上,它还进一步渗透到汽车、电视、天猫精灵等智能终端里,挪动利用能够通过 Android 运行在这些设施上。而 Kubernetes 也有这样的后劲或发展趋势,当然它不是呈现在智能家电中,而是呈现在各家私有云、自建机房,以及边缘集群。能够料想,Kubernetes 将来会像 Android 一样无处不在。 那么,有了 Kubernetes 这层交付当前,容器 + Kubernetes 这层界面是不是就能够解决掉所有的交付问题了?答案必定不是。试想,如果咱们的手机中只有 Android 零碎,它可能满足咱们工作和生存需要吗?不能,必须有各种各样的软件应用才行。对应到云原生,它除了 Kubernetes 这个 “操作系统” 外,也须要一套利用的交付能力。在手机中,软件应用能够通过相似“豌豆荚”这样的利用以便用户装置,同样在云原生时代,咱们也须要将利用部署到不同的 Kubernetes 集群上。但因为 Kubernetes 海量琐碎的设施细节与简单各异的操作语言,导致部署过程中会遇到各种各样的问题,这时就须要云原生的“豌豆荚”来解决这个问题,也就是利用治理平台,去屏蔽交付的复杂性。 利用治理平台在业界有两种支流模式,第一种是传统平台模式,在 Kubernetes 上 “盖一个大帽子” ,将所有复杂度屏蔽,在此之上,再依据需要本人提供一层简化的利用形象。通过这种形式,尽管利用平台变得易用了,但新的能力须要由平台开发实现,也就带来了扩大难、迭代迟缓的问题,无奈满足日益增长的利用治理诉求。 ...

November 24, 2021 · 2 min · jiezi

关于devops:打破开发项目管理困境联电的数字化转型实践分享

联结汽车电子有限公司(以下简称联电)成立于1995年,是中联汽车电子有限公司和德国罗伯特·博世有限公司在中国的合资企业,次要从事汽油发动机管理系统、变速箱控制系统、车身电子、混合能源和电力驱动控制系统的开发、生产和销售。联电无效整合本地劣势和寰球当先的技术为国内各汽车厂商提供优质产品和服务,并为满足日益严格的法规要求提供技术支持。 联结电子汽车有限公司宣传图 联电面临的数字化转型窘境近年来,为更好地适应业务倒退,联电全面推动企业信息化策略,特地是生产制作与信息化的整合。除了凭借自身雄厚的IT力量进行信息化建设外,联电也引入了许多内部供应商合作伙伴,心愿可能借助内部力量,实现麻利化的利用交付和自动化的经营治理,减速数字化转型。 在此过程中,联电面临着诸多开发项目管理窘境,如: • 一个项目经理对接多个合作伙伴,随着合作伙伴的我的项目越来越多,需要起源越来越丰盛,梳理起来十分艰难; • 应用传统的瀑布式开发模式,我的项目开发周期较长,开发进度赶不上需要变动,很容易延期,我的项目进度难以把控; • 各个开发团队应用的开发工具不统一,难以协调对立的开发部署形式,我的项目间的对接成为难题。 引入猪齿鱼平台,大大晋升开发效力为了解决上述问题,联电决定引入猪齿鱼产品晋升开发项目管理效力。猪齿鱼数智化效力平台,致力于为企业传递体系化方法论,提供合作、测试、DevOps及容器工具,帮忙团队效力更快更强更稳固。 猪齿鱼数智化效力平台 图 在引入猪齿鱼后,联电采纳“Quick-HAND”+ “麻利”施行办法进行我的项目施行,实现了对外部供应商的对立治理和产品生命周期治理,大大提高了我的项目开发和交付的效率。 猪齿鱼在联电的我的项目开发治理中,次要起到的作用是: • 帮忙联电合作伙伴团队治理产品布局、开发及经营的全生命周期,更加频繁疾速的交付产品的性能; • 帮忙团队造成麻利治理标准、DevOps标准以及开发标准,标准供应商的开发治理; • 通过我的项目施行,造就出多支相熟麻利治理方法论和深谙麻利实际的外部参谋和IT团队,为团队做好了重要的技能和人才储备。 Quick-HAND+麻利 图 对联电的客户而言,猪齿鱼的利用带来的好处多多,包含: • 我的项目进度更容易把控:联电项目管理人员可同步治理多个我的项目的需要,实时理解我的项目开发进度 • 效率晋升:突破传统的瀑布开发模式,应用麻利+DevOps的开发模式,标准各个我的项目软件开发流程,缩短应用服务开发周期,实现继续交付 • 品质晋升:对我的项目麻利开发、代码开发、测试治理、部署运维等各个阶段的开发流程进行治理和监控,保障产品质量 从团队协同到DevOps工具链、从平台工具到体系化方法论,猪齿鱼全面帮忙联电晋升协同治理与工程效率,贯通端到端全流程,帮忙联电高效推动数字化转型降级。 本文由猪齿鱼技术团队原创,转载请注明出处:猪齿鱼官网 对于猪齿鱼 猪齿鱼Choerodon数智化效力平台,提供体系化方法论和合作、测试、DevOps及容器工具,帮忙企业拉通需要、设计、开发、部署、测试和经营流程,一站式进步管理效率和品质。从团队协同到DevOps工具链、从平台工具到体系化方法论,猪齿鱼全面满足协同治理与工程效率需要,贯通端到端全流程,助力团队效力更快更强更稳固,帮忙企业推动数智化转型降级。戳此处试用猪齿鱼

November 24, 2021 · 1 min · jiezi

关于devops:Terraform初探管理AWS-Lightsail实例

前言Terraform是一种开源基础设施及代码(IaC)的工具,可提供统一的CLI(命令行接口)工作流来治理数百个云服务,将云API编码为申明性的配置文件进行治理。 本文创立一个治理AWS Lightsail实例的例子来入门Terraform的应用。 装置Terraform CLI要应用Terramform,首先要在本地零碎装置Terraform命令行工具。HashiCorp提供了预编译好的二进制散发包,能够通过(https://www.terraform.com/dow...) 间接下载相应平台的二进制包,解压后放到相应的执行门路。也能够通过一些软件包管理工具装置,例如在Linux/OS X上通过LinuxBrew/HomeBrew进行装置,在Windows上通过Chocolatey进行装置。 这里咱们示例在Linux上是应用LinuxBrew进行装置 > brew install terraform装置实现后,能够查看其版本 ❯ terraform -versionTerraform v1.0.11on linux_amd64应用-help查看其可用命令,装置胜利后,咱们就能够应用Terraform来创立相应的基础设施我的项目了。 AWS账号筹备本文将通过创立一个治理AWS Lightsial实例的我的项目来尝试Terraform,因而须要一个AWS账号,以及在本地环境装置和配置好AWS CLI工具的拜访凭据。 装置和配置AWS CLI,请参考其文档 (https://docs.aws.amazon.com/c...) 。 配置实现之后,能够在本地命令行终端拜访相应的AWS资源。 创立并初始化Terraform我的项目Terraform在本地通过文件夹来治理一个基础设施我的项目的申明性代码,例如咱们在本地创立一个文件夹 > mkdir mylightsail> cd mylightsail/进入文件夹后,创立一个以 .tf 作为后缀的文件,例如 main.tf > touch main.tf而后应用编辑器关上文件进行编辑,写入以下代码块 terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 3.65" } }}# Configure the AWS Providerprovider "aws" { region = "ap-southeast-1"}其中 terraform/required_providers 块定义了该我的项目须要的 Provider,Terraform是通过不同的Provider来治理相应的基础设施资源的,可到 (https://registry.terraform.io) 来查找须要的Providers,例如GCP,Azure以及阿里云等的Providers。这里因为咱们要治理的资源是AWS Lightsail实例,所以应用了Hashicorp官网提供的 hashicorp/aws 。 ...

November 23, 2021 · 4 min · jiezi

关于devops:网不好怎么办TLS握手带宽直降80BabaSSL是怎么做到的-龙蜥技术

简介:为了保障数据的安全性,客户端会先和服务器进行 TLS 握手,有什么方法能够缩小 TLS 握手的带宽耗费呢? 编者按:BabaSSL 是一款开源的明码库产品,在 GitHub 和龙蜥社区开源,并退出到龙蜥社区(OpenAnolis)的商密软件栈 SIG 组,且作为 Anolis 商密 OS 的外围组件之一。本文作者张成龙(刻一),是蚂蚁团体技术专家,负责BabaSSL明码库产品,也是OpenSSL贡献者之一。 前言随着 5G 网络的建设,减速了挪动互联网利用的倒退,包含短视频、在线教育、物联网等畛域。然而在现实生活中,仍然存在网络信号不好的场景,包含地下商场、车库、地铁等中央,或者是因为网络拥塞导致的弱网环境下,利用在应用过程中加载迟缓,导致用户体验变差。这时候就须要对弱网环境进行优化,而伎俩之一就是想方法升高网络数据传输。 为了保障数据的安全性,通常应用 TLS/SSL 进行加密传输。当客户端拜访服务器后盾时,客户端会先和服务器进行 TLS 握手。在 TLS 残缺握手时,服务端会发送证书链用于身份认证,而握手时数据传输的大部分都来自于证书。 有什么方法能够缩小 TLS 握手的带宽耗费呢?如果证书能够被压缩,甚至“隐没”,那就能够大大降低数据传输。RFC 8879 TLS Certificate Compression 就是为了解决这个问题,在 TLS 1.3 握手时提供证书压缩性能。 BabaSSL 是一款开源的明码库产品,在 GitHub 和 OpenAnolis 龙蜥社区开源,并退出到龙蜥社区(OpenAnolis)的商密软件栈 SIG 组,且作为 Anolis 商密 OS 的外围组件之一,代替 OpenSSL 成为零碎默认的根底明码算法库;基于 OpenSSL 1.1 版本并放弃兼容性,在 OpenSSL 的根底上实现了一系列自主可控的平安个性,包含各种国密算法、国密规范的实现以及大量进步密钥平安强度的个性实现。目前,BabaSSL 曾经反对 TLS 证书压缩性能,而 OpenSSL 还不反对。 TLS 证书压缩介绍 1、如果客户端反对证书压缩,在 ClientHello 音讯中携带 compress_certificate 扩大,该扩大中蕴含反对的压缩算法列表; 2、服务端收到 ClientHello,发现对方反对证书压缩,如果服务端也反对证书压缩,同时反对客户端申明的压缩办法,则应用该算法压缩 Certificate 音讯; ...

November 23, 2021 · 2 min · jiezi

关于devops:阿里大规模业务混部下的全链路资源隔离技术演进

简介: 本文作为混部实际系列开篇,本篇文章将介绍资源隔离技术在混部中的重要性、其落地挑战及咱们的应答思路。 作者:钱君、南异 混部顾名思义,就是将不同类型的业务在同一台机器上混合部署起来,让它们共享机器上的 CPU、内存、IO 等资源,目标就是最大限度地进步资源利用率,从而升高洽购和经营等老本。 2014 年,阿里开始了第一次摸索混部,通过七年磨难,这把将资源利用率大幅晋升的利剑正式开始商用。 通过计算资源、内存资源、存储资源、网络资源等全链路的隔离以及毫秒级的自适应调度能力,阿里能够在双十一的流量下进行全时混部,通过智能化的决策与运维能力,撑持着外部百万级的 Pod 混部,不论是 CPU 与 GPU 资源,一般容器与平安容器,包含国产化环境各种异构基础设施,都能实现高效混部,这让阿里外围电商业务生产集群老本降落了 50% 以上,同时让外围业务受到的烦扰小于 5%。 针对云原生时代的资源效力晋升问题,咱们将基于大规模场景下的混部实际推出系列文章,具体介绍并分享对于混部技术的细节,及大规模生产中碰到的种种落地的理论问题。作为系列开篇,本篇文章将介绍资源隔离技术在混部中的重要性、其落地挑战及咱们的应答思路。 混部和资源隔离之间的关系:资源隔离是混部的基石混部通常是将不同优先级的工作混合在一起,例如高优先级的实时工作(对时延敏感,资源耗费低;称为在线)和低优先级的批处理工作(对时延不敏感,资源耗费高;称为离线),当高优先级业务须要资源时,低优先级工作须要立刻偿还,并且低优先级工作的运行不能对高优先级工作造成显著烦扰。 为了满足混部的需要,在单机维度的内核资源隔离技术是最为要害的一项技术,阿里云在内核资源隔离技术上深耕多年,积攒了许多业界当先的教训,咱们将这些内核资源隔离技术次要波及的范畴概括为内核中的调度、内存和 IO 这三大子系统,并且在各个子系统畛域依据云原生的混部场景进行了深刻的革新和优化,包含 CPU Group Identity、SMT expeller、基于 Cgroup 的内存异步回收等。这些要害的技术使客户有能力在云原生混部场景中依据业务特点给出最优解决方案,无效进步用户的资源使用率并升高用户资源的应用老本,十分实用于容器云混部场景,同时也是大规模化混合部署计划所强依赖的关键技术。 下图是资源隔离能力在整个混部计划中的地位: 为什么须要资源隔离,资源隔离会遇到哪些拦路虎假如咱们当初有一台服务器,下面运行了高优的在线业务以及离线工作。在线工作对响应工夫 (Response Time, RT) 的需要是很明确的,要求尽可能低的 RT,故被称之为提早敏感型 (Latency-Sensitive, LS) 负载;离线工作永远是有多少资源吃多少资源的,故此类负载被称之为 Best Effort (BE)。如果咱们对在线和离线工作不加干预,那么离线工作很有可能会频繁、长期占用各种资源,从而让在线工作没有机会调度,或者调度不及时,或者获取不到带宽等等,从而呈现在线业务 RT 急剧升高的状况。所以在这种场景下咱们须要必要的伎俩来对在线和离线容器进行资源应用上的隔离,来确保在线高优容器在应用资源时能够及时地获取,最终可能在晋升整体资源使用率的状况下保障高优容器的 QoS。 上面让咱们一起看看在线和离线混跑时可能呈现的状况: 首先,CPU 是最有可能面对在离线竞争的,因为 CPU 调度是外围,在线和离线工作可能别离会调度到一个核上,互相抢执行工夫; 当然工作也可能会别离跑到互相对应的一对 HT 上,相互竞争指令发射带宽和其余流水线资源; 接下来 CPU 的各级缓存必然是会被消耗掉的,而缓存资源是无限的,所以这里波及到了缓存资源划分的问题; 即便咱们曾经完满解决了各级缓存的资源划分,问题依然存在。首先内存是 CPU 缓存的下一级,内存自身也相似,会产生争抢,不管在线或离线工作,都是须要像 CPU 缓存一样进行内存资源划分的; 另外当 CPU 最初一级缓存 (Last Level Cache, LLC) 没有命中的时候,内存的带宽(咱们称之为运行时容量,以有别于内存大小划分这种动态容量)会变高,所以内存和 CPU 缓存之间的资源耗费,是相互影响的; ...

November 22, 2021 · 2 min · jiezi

关于devops:今年双11阿里业务100上云

简介: 阿里巴巴业务的研发效率晋升了20%、CPU资源利用率晋升30%、利用100%云原生化、在线业务容器可达百万规模,同时计算效率大幅晋升,双11整体计算成本三年降落30%。 明天,阿里巴巴首席技术官程立发表——2021天猫双11是首个100%的云上双11,整体计算成本三年降落了30%。 程立走漏,要把阿里巴巴的业务全副迁上公共云,挑战微小,不仅要保障业务不中断,还需应答期间可能呈现的突发状况。 今年年初,阿里巴巴把最沉重的一个业务——搜寻业务顺利搬到了云上,而消费者和商家对这个“开着飞机换引擎”的过程毫无感知。 阿里是寰球首家将所有业务都放在自家公共云上的大型科技公司,这意味着阿里云有能力应答高难度简单环境下的技术挑战。 程立说,上云带来的益处不言而喻: 阿里巴巴业务的研发效率晋升了20%、CPU资源利用率晋升30%、利用100%云原生化、在线业务容器可达百万规模,同时计算效率大幅晋升,双11整体计算成本三年降落30%。 这些晋升源于交易链路的大幅优化,通过对立资源池进行调度,撑持大规模的离在线混部,实现在线业务优先调度,应答脉冲式的流量冲击。 作为世界上规模最大的数字工程之一,双11是对阿里技术的“大考”。 从2014年采纳自研数据库承载交易系统、2015年实现寰球最大规模的混合云架构、2019年外围交易系统上云,再到往年全栈自研技术支持双11,包含自研芯片和服务器投入超大规模实战、数百台小蛮驴物流机器人全国配送等。 大规模开释的技术红利,让消费者和商家享受到丝般顺滑的体验。 阿里自研技术双11都在忙些啥↓ 原文链接本文为阿里云原创内容,未经容许不得转载。

November 18, 2021 · 1 min · jiezi

关于devops:干货分享细说双-11-直播背后的压测保障技术

简介: 阿里云 PTS 站在双 11 伟人的肩膀上,是阿里全链路压测的延长。PTS 通过伸缩弹性,轻松发动用户百万级别的流量,免去机器、人力老本;PTS 对流量的管制,可能实时脉冲,精准管制; 是应答视频直播疾速攀升的流量脉冲的优良计划。 作者:子矜 “往年 1 月到当初,淘宝直播的用户超过了 5 亿,到 8 月份流量也增长了 59%,在最外围的商家 GMV 上增长了 55%。双 11 是从 10 月 20 日晚开始的,咱们心愿淘宝直播作为主场去承接这件事件。”日前,淘宝事业群直播事业部负责人程道放在承受 21 世纪经济报道记者采访时走漏,过来一年的直播堪称冷落,往年会更加专业化。 如此大的用户体量下,直播类利用给后端服务带来了一些什么不一样的挑战呢?咱们明天来介绍一些直播的架构,以及针对这个架构,给咱们的利用架构带来的挑战。 直播的架构咱们通常看到的有上面几种直播: 单人直播,例如淘宝直播,通常随同着秒杀,弹幕,送火箭等业务逻辑;多人同时直播,例如连麦,会议;录播,对于局部直播场景如培训、会议等,须要将现场直播视频保留以进行流传、留存等应用,有对直播进行录制的需要。这种往往对实时性要求不高。而当用户观看直播时,如果服务接入了 CDN,若接入 CDN,播放端抉择就近的 CDN 节点进行拉流播放,此时拉流压力在 CDN;若未接入 CDN,播放端从直播源站进行拉流。 下图是一个比拟常见的视频流的架构和两条数据走向: 视频流推拉逻辑,如蓝色线所示惯例的业务逻辑,如黄色线所示能够看到有四个次要模块: 推流端:次要的作用在于采集主播的音视频数据推送到流媒体服务端;流媒体服务端:次要作用在于把推流端传递过去的数据转换成指定格局,同时推送到播放端不便不同播放端用户观看,当然目前云产商也流媒体服务端的一整套解决方案;业务服务端:次要解决一些常见的业务逻辑,如秒杀,弹幕等等;播放端:播放端简而言之就是拉取音视频进行播放,把相应的内容出现给用户。四个要害的模块的协定其实就是流媒体传输协定。大部分直播的构造都采取上图的格局,较大的区别是是否引入 CDN。一般来说,咱们倡议客户引入 CDN 来缩小直播流量对服务器的冲击。四个模块之间的协定并不着重强调一致性。 接下来,咱们沿着这个架构来讨论一下,在这其中比拟软弱的危险有哪些,以及咱们如何提前通过压测来排查这些危险点。 直播中的挑战挑战一:视频流给流媒体服务端的压力 在这个推拉的逻辑中,因为波及视频的流量较大,通过的路线较长,对流媒体服务器都会造成冲击;通场的做法是引入 CDN,当用户开始收看视频的时候,会先就近去 CDN 拉取流,如果这个时候视频内容还没有缓存在 CDN 的时候,CDN 就回源到流媒体服务端。 然而,危险就存在在霎时大量用户同时收看 CDN,CDN 大量回源的时候;这种脉冲流量,会给流服务端带来不可预计的成果。 咱们通常通过压测来提前验证链路的有效性,甚至能够通过压测,提前把视频在 CDN 预热。然而,传统的 HTTP 申请协定是无奈反对这种场景的,因为: 即便开源软件 srs_bench,以及 JMeter 都提供了一些插件来应用。然而这些开源软件须要用户对视频协定有比拟深刻的了解,应用门槛会稍微偏高;视频压测自身对带宽的要求十分高,这就象征压测机器老本比拟高;视频压测须要思考到地区对传输品质的影响。针对以上问题,PTS 退出了 RTMP/HLS 协定,并且联合压测场景做了形象,让用户能够界面化的应用不同协定的压测。 ...

November 17, 2021 · 1 min · jiezi

关于devops:三一集团数字化转型探秘以DevOps平台构建敏捷研发体系

三一团体开创于1989年,是寰球配备制造业的当先企业之一,同时也是中国“智能制作”首批试点示范企业。在立足配备制作主营业务根底上,三一团体大力发展新能源、金融保险、住宅产业化、工业互联网、军工、消防、环保等新业务,已成为国内风电成套解决方案和可再生清洁能源的提供者,同时也是中国最成熟的PC成套拆卸提供商。 目前,三一团体混凝土机械稳居世界第一品牌,开掘机械在国内市场已间断十年蝉联销量冠军。2020年三一团体共销售98705台挖掘机,占据寰球挖掘机市场15%的份额,首夺寰球销量冠军;起重机产品长年占据行业前三,桩工机械、掘进机械、港口机械稳居中国第一。 三一团体始于1989 面对数字化转型,三一团体的时机与挑战并存随着中国经济步入“新常态”,中国工业企业面临的创新能力有余问题正日趋显著,数字化转型已到了一个关键时期,这对于整个行业而言既是挑战、更是时机。进入工业互联网时代,市场对于产品自身的价值赋能要求越来越高,倒逼行业开始加码向数字化、智能化方向倒退。在这样的背景下,依靠于数字化、自动化、先进剖析、虚拟现实和加强事实、以及工业物联网等先进技术的灯塔工厂,被视为第四次工业革命的领军者。 作为中国工程机械巨头,三一团体抓住机遇,减速数字化的转型,由具备胆识的决策者为三一团体制订数字化转型的顶层策略。团体董事长梁稳根示意:“三一的数字化转型,要么翻身,要么翻船!”团体董事、执行总裁兼总工程师易小刚示意:“三一将把数字化智能化转型、助力‘三高四新’策略施行作为倒退的大前提和大逻辑,紧跟数字化反动潮流,紧抓智能制作大势,瞄准国内当先、国内一流,致力成为中华民族的世界级品牌。” 以后,传统制造业数字化转型面临着一些挑战,在软件方面,目前行业内许多仿真软件来自美国,工业控制软件则少数来自德国,国内本人的软件应用还不多,少数企业打算以云原生技术来研发并实现软件代替。三一团体紧跟时代步调,一直摸索新技术,将以后的容器、DevOps、微服务为外围的云原生技术列入新的战略规划,但简单的工业软件要转化成云原生的工业软件,须要投入大量的人力物力。 三一团体面临着两大挑战: 治理方面:瀑布式开发模式下软件交付周期长,需要治理不清晰、变更频繁,过程中短少可视化看板,品质难量化;内部零碎协同的需要,无奈及时同步信息,导致需要交付延期。开发方面:代码分支治理较为凌乱无序;发版流程繁琐、无制度,版本回退麻烦;人工测试,测试报告编制繁琐,无自动化测试;代码品质治理,人工查看,交付品质等。依靠猪齿鱼搭建DevOps平台,建设具备长期竞争力的技术中台为了应答数字化转型的时机与挑战,三一团体于2020年正式启动技术中台我的项目。通过搭建DevOps平台、微服务治理平台、容器云三大平台,三一团体构建技术中台,将其作为团体数字化转型的重要技术底座,以实现基础架构麻利化、开发运维一体化、服务经营化为指标,打造三一团体麻利开发体系,实现软件研发的全生命周期治理,实现核心技术资产的积淀,进步软件交付能力和程度。 在搭建技术中台的选型中,三一团体采纳汉得信息自研的猪齿鱼Choerodon数智化效力平台来搭建技术中台的DevOps平台。该产品提供体系化方法论和合作、测试、DevOps及容器工具,帮忙企业拉通需要、设计、开发、部署、测试和经营流程,一站式进步管理效率和品质。从团队协同到DevOps工具链、从平台工具到体系化方法论,猪齿鱼帮忙三一个体拉通需要、设计、开发、部署、测试和经营流程,贯通端到端全流程,从而使得三一团体可能更好地进行软件研发的全生命周期治理,让团队效力更快更强更稳固。 猪齿鱼 数智化效力平台 同时,三一团体技术中台也采纳汉得企业级PaaS平台HZERO作为微服务开发框架。通过云原生技术和微服务架构,该产品提供对立的根底技术服务组件,防止零碎间反复建设,为利用开发和解耦提供对立框架,帮忙三一团体更聚焦于业务场景化的研发与利用。 以DevOps平台构建麻利研发体系,减速数字化转型三一团体技术中台以云化底座为根底,以DevOps平台和微服务开发框架为抓手,基于优化的麻利软件开发治理流程,加上施行麻利开发的管理工具,最终建设起了软件研发自动化治理流水线,促成了软件研发效率及品质晋升。帮忙三一团体现有软件的开发过程向标准化、自动化、高效化的“流水线模式”转型,大大晋升了业务麻利和开发效率、升高IT建设和运维老本、晋升IT建设品质,保障了企业的数字化转型降级。 全生命周期治理-基于“流水线”的软件生产全过程设计 项目管理方面:三一团体应用平台进行需要的全生命周期治理,极大地缩短需要响应周期,从一个月缩短至一周;我的项目工作的可视化治理,让工作聚焦、通明、易跟踪,继续改善和晋升研发协同;辅助我的项目进行治理的各种报表,包含麻利治理报表、DevOps报表、测试报表等。 软件开发方面:三一团体将开发过程中的各个环节串接起来,实现全流程自动化,缩小工作量,进步开发效率;自动化代码查看, 保障代码标准,晋升代码品质,代码重复性和错误率缩小90%;软件研发整体的测试治理,包含测试用例、测试计划、测试报告、API测试、自动化测试、性能测试。 总体来说,该技术中台提供的DevOps、微服务以及容器云,可能无效反对云化解耦,来实现软件的轻量化,使技术架构走向智能化,帮忙三一产业链上的中小企业通过云架构实现软件赋能,继续推动数字化转型降级,是三一团体进步研发能力的得力工具,也是三一团体数字化转型的助推器。 在此过程中,汉得的猪齿鱼效力治理平台产品,对DevOps平台的搭建起到了重要作用。三一团体流程信息化总部总监吕青海介绍到:“弱小的软件能力是三一数字化转型的重要推动因素之一,构建这种能力须要一个自主、开源的软件开发治理平台,以反对灵便麻利的软件开发过程治理、积攒并欠缺自主开发框架与组件、自动化部署与运维、无缝集成三一的微服务治理平台以及容器云平台。通过全面的比照当前,咱们抉择了汉得的猪齿鱼Choerodon来搭建DevOps平台,该平台也成为三一技术中台的重要组成部分,为三一的软件能力晋升打下了松软的技术根底,施展了重要的踊跃作用。” 以DevOps平台构建麻利研发体系,减速数字化转型!在将来,猪齿鱼数智化效力平台将持续提供体系化方法论和一系列的研发管理工具,帮忙更多客户进步经营效率和研发治理能力,助力更多企业的企业数字化转型策略落地。 本文由猪齿鱼技术团队原创,转载请注明出处:猪齿鱼官网 对于猪齿鱼 猪齿鱼Choerodon数智化效力平台,提供体系化方法论和合作、测试、DevOps及容器工具,帮忙企业拉通需要、设计、开发、部署、测试和经营流程,一站式进步管理效率和品质。从团队协同到DevOps工具链、从平台工具到体系化方法论,猪齿鱼全面满足协同治理与工程效率需要,贯通端到端全流程,助力团队效力更快更强更稳固,帮忙企业推动数智化转型降级。戳此处试用猪齿鱼

November 12, 2021 · 1 min · jiezi

关于devops:藏书馆App基于Rainbond实现云原生DevOps的实践

藏书馆App基于Rainbond实现云原生DevOps的实际咱们须要的不是精通Kubernetes的工程师,咱们须要一款小白都能用好的管理工具。 —— 厦门正观易知科技有限公司运维负责人 郭传壕 大家好,我是厦门正观易知科技有限公司运维负责人郭传壕。 藏书馆是一个专一用户自我成长的云端私人图书馆,集电子书的读、荐、借、购、存和常识治理性能于一体,致力于用户的认知赋能,通过读书习惯的养成,达成自我成长。目前累计注册用户已达 1500W ,平台图书资源超过200W册。 咱们应用Rainbond曾经有2年,我把咱们的应用教训分享给大家。 1.以前的困局处于云原生时代中的藏书馆的终点很高,咱们一开始就选定了微服务架构、Kubernetes、容器化等合乎时代潮流的技术体系。然而原生的kubernetes 治理平台提供的性能并不完全符合咱们的预期,二次开发的微小技术老本也是咱们累赘不起的。 在理解到 Rainbond 之前,处于守业初期的咱们始终受困于产品迭代变更频繁所带来的琐事之中。我所说的琐事蕴含微服务架构下50个服务的版本治理、构建产物的更替、线上环境的公布以及围绕着利用从开发到上线再到运维的种种繁琐工作。 咱们心愿能够从这些琐事中跳脱进去,专一于业务自身,摸索出一条适宜kubernetes环境下继续开发、继续交付的简捷之路。 鉴于此,咱们开始踊跃的寻找一款开源且易用的利用治理平台。 2.初识 Rainbond在 Rainbond 之前,咱们曾经尝试过了 Rancher 等产品,但产品性能和咱们的预期有很大差距。 2 年前,咱们通过 Github 第一次理解到了 Rainbond 这款产品,惊喜于性能十分符合藏书馆的需要。列举几个令人印象粗浅的能力: 利用架构的整体拓扑图以上帝视角,和盘托出的观测到所有服务组件的运行状态与依赖关系。强迫症会逼着咱们的工程师毁灭红色的异样状态,而体现运行状态的绿色真的令人感到安心。可视化的资源占用状况资源占用状况是体现可观测性很重要的指标。对于初创公司而言,理解资源分配是否正当,杜绝资源节约是很重要的。Rainbond 从团队到服务组件的每个维度都提供了良好的可观测性。团队级别的资源限额能力十分实用,解决了运维团队无奈无效掌控资源分配的难题。主动伸缩藏书馆是一个典型的 2C 场景,如何利用好云计算提供的弹性,灵便的应答流量顶峰呢?答案就是应用主动伸缩性能。Rainbond 提供的主动伸缩性能,突出了简略易配置的特点。主动伸缩能力极大的解放了运维团队的工作压力,从此远离调兵遣将和壁垒森严。要害业务会随着咱们的情意,主动扩张,直到可能吞吐所有流量。集中式的网关策略管理2C 场景下的服务公布,是无论如何也绕不过来的坎儿。无论是蓝绿公布、灰度公布抑或是A/B测试,这服务公布相干的十八般武艺多少都会碰到。原生的 Kubernetes Ingress 确实能够实现这些公布策略,然而咱们更心愿失去一个产品化的集中式治理页面来解决这些问题,而不是去麻烦运维工程师们去碰那些格局严苛的Yaml文件。Rainbond 网关策略管理完满的实现了咱们的需要。利用复制疾速生成环境在藏书馆的开发流程中,咱们时常须要搭建各种环境,来辨别开发、测试、预公布场景,别离对应不同版本的微服务组件,比方Dev、Prod之类的。但如果每次生成环境都要手动创立服务组件,那真的太低效了。利用复制性能在这个场景下十分有用,它帮忙我疾速复制出一套环境进去。复制过程中自助抉择构建源的版本,对我而言是镜像的 Tag。复制后的新环境,保留了所有的服务组件元信息以及依赖关系。在逐渐的摸索过程中,和官网团队在社区中进行的互动,让咱们少走了很多弯路。一款开源产品如果随同着有生命力的社区,将会是十分令人安心的。 3.开发测试环境部署第一步,部署微服务 上手 Rainbond ,是从部署单个微服务开始的,这个过程非常简单,不须要学习Kubernetes的 Yaml 。开发环境中的组件是基于镜像构建实现的,只须要按界面的疏导填写好镜像地址及相干信息就能够了。 咱们用的是 Spring Cloud 微服务框架,在 Rainbond 体系下能够很好的运行,我在部署过程中受到了一系列文档的影响,这里分享给大家: Spring Cloud 微服务部署在 Rainbond 的劣势Spring Cloud 微服务与 Service Mesh 的交融Spring Cloud 微服务部署在 Rainbond 的案例第二步,通过可视化的形式服务编排 在编排微服务的过程中,基于图形化编辑组件依赖关系这个性能,着实惊艳了我。这种编排形式和其余平台基于简单 Yaml 文件进行编排的形式有极大的不同。感兴趣的小伙伴们能够浏览下服务编排相干的形容,这确实是一种小白都能够掌控的微服务编排形式。 ...

November 1, 2021 · 1 min · jiezi

关于devops:四Jira-Dashboard

1.Dashboard介绍Dashboard是Jira提供的数据展现的大屏,为团队提供数据分析性能。 2.Dashboard创立Dashboard的创立分为2步,第一步创立Dashboard,第二步在Dashboard外面增加小程序。 2.1.创立Dashboard创立Dashboard步骤如下,创立时能够配置查阅器(谁能够看),编辑器(谁能够编辑)。 2.2.增加小程序增加小程序,分为3步。第1步抉择小程序,第2步抉择筛选器,第3步抉择展现内容。1.抉择小程序并增加小程序 2.抉择筛选器并抉择展现字段 3.展现后果

October 26, 2021 · 1 min · jiezi

关于devops:微软比特熊故事汇10月英雄故事热爱即分享上云加技能

大家好!我是爱吃、爱玩、更爱学习技术,IT届的新晋网红,开发者的好敌人—比特熊! 最近火到没边的《鱿鱼游戏》大家看了吗? 比特熊:本熊看的时候就在想,这个赛博安娜贝尔一样的木偶必定用了包含AI、图像识别在内的很多云技术,实现得还挺好的。 【比特熊故事汇】作为比特熊直播间系列栏目的首发,将定期邀请技术大牛和行业先锋做客。这里不仅讲最“热”的技术,还有更多待解锁的集体故事和趣味话题!在这里打个广告,欢送酷爱技术分享、有故事的敌人来到比特熊的直播间! 比特熊:这次的【比特熊故事汇】邀请到了三位微软MVP——刘海峰、蔡孟玹(Alan Tsai)、闫晓迪。来到【比特熊直播间】现场的是海峰老师,Alan和闫晓迪老师在台北和新西兰,通过线上的模式一起退出。大家一起聊聊“云”的实在应用感触、上云的挑战和顾虑、实例demo,商用实际、精彩集体故事分享,亮点多多。谁取得过“最佳吐槽奖”,又有哪位喜爱电影还有小说? 比特熊直播间首次尝试线上线下的联动模式,心愿大家喜爱,咱们能够无惧空间局限给大家邀请到更多违心分享的老师。 比特熊:咱们这期的主题是 “云上起舞”,对于熊仔来说有些艺术,有点形象。这个短句的神秘如何解析,就请现场的海峰老师给大家讲一讲吧。 海峰:那我就从本人和Azure的渊源说起吧。我大学毕业后成为了一个开发者,一个网站建起来当前要去部署,最大的问题就是服务器总被黑,那时候有破绽,还没有所谓的“云”。就算把服务器的安全策略做得经典一点,各种服务器也很难把控。 服务器的性能十分多,然而我做web开发,我只须要其中一小部分,把我的站点跑起来,其它的我不想关怀。那时咱们就想有没有可能做一个服务零碎(那时还没有“云”)。因为一个机缘我有机会参加了微软Azure的测试,那时候还没有大陆版和Globe版的概念。 如果理解Azure的人应该晓得,最早的时候Azure是没有虚机的,没有VM。过后去做测试,好多敌人说:微软的云是不错,它为什么没有虚机呀。甚至当初好多敌人一说到云计算,就感觉是虚机。包含最早做IDC的时候,做个VPS可能就是叫所谓的“云计算”,实际上那不是真正的云。 真正的云应该是什么——PaaS级的利用,这也是微软的初衷,为什么不做VM,起初没有方法,因为PaaS级利用大家实际上手还是比拟吃力的,当初甚至好多人只晓得PaaS的概念,怎么用,不了解。 微软在这方面做了很多工作,而且底层也做的绝对比拟齐备。因为微软有人造的劣势,大家如果是老鸟或是个老程序员的话,应该都有这个经验,最早做服务器开发的时候破绽很多,要解决很多不是咱们开发该干的事,有了PaaS当前就很好地解决了这些问题。 咱们公司也是微软的partner,2014年参加了Mooncake的落地,Mooncake就是从Globe版到世纪互联版的我的项目。咱们做了一个平台叫51Aspx,大家如果是.Net开发可能理解过咱们的平台,咱们的平台最早开发原生都是在Azure上进行的,咱们整个的开发部署都是用PaaS级的利用,咱们能够做到弹性伸缩,不必去过多的运维。 这其实也圆了我最早作为开发者的一个幻想,只关怀我的代码,其它货色不care,比方整个服务器的运维,硬件的保护。大家如果有相似的经验,就会晓得还是蛮苦楚的,那时候咱们在电信的机房,戴尔的服务器那么多,中午手机都不敢关机,你不晓得什么时候服务器就当掉了。比如说风扇坏了,不散热就down掉了。当初用了云当前,就不存在这些问题了。 Alan:海峰老师介绍了很多内容,我再延长一点点。咱们都晓得上云是势不可挡的,就像海峰老师说的VM是大家最相熟的,本质上VM到治理的货色切实是太多了。所以PaaS真的十分不便,如果你是开发者的话,其实你只须要关注你的开发,PaaS就把一些事件做好了。 大家都晓得上云是趋势,可是为什么推动还是比拟艰难,我感觉起因之一是既有的IT人员会放心:是不是上云了之后就不须要我了,我的一些技能是不是就没方法应用了。 我感觉咱们要跟着这个时代,不论企业有没有筹备好,能够先把本人筹备好。我就这里就飞快地给大家看两个画面,咱们举个例子,任何应用程序里肯定会有两个货色,一个是数据库,另一个是用来运算的服务。数据库咱们会用到Azure的SQL Database。数据库最常要留神的是什么——高可用和数据安全。这方面,如果用Azure SQL Database的PaaS服务的话那你就只须要按几个按钮,点一点就完结了。 另外一个环节就是运算,大家能够看到在App Service外面就是微软PaaS的服务,那最常遇到的需要就是我想做一些扩大,也是点一点就做完了。咱们能够设定某一个规定,比如说CPU过载超过多少工夫就主动延展。 比如说我晓得每个周末,在特定的工夫会有十分多的人,设定好了之后到那个工夫点,它就会主动帮你做延展。咱们讲到利用的时候,都会想到部署的事,怎么能够疾速地部署,如果服务器坏掉,怎么能够疾速启动另一个,这就会延长到晓迪老师等下跟咱们介绍的DevOps。 晓迪:方才听海峰和Alan讲的,我有一种感觉,叫心有戚戚焉。咱们回忆本人的从业经验,我是从2000零几年开始做软件开发,咱们做布署公布的时候,编译进去那个DAL,咱们要手动把它拷贝到服务器上。人工操作常常会有各种各样的问题,比方拷错了,版本出问题。还有一个问题是本地开发环境和服务器不统一,程序员常常有一种说法:在我的机器上为什么是好的,怎么到你那就不好使了。 当初咱们能够用云服务,简略地实现缩放,实现资源的配置。咱们开发的程序,怎么把它很疾速地交付给咱们的用户,这也是很重要的一个点。微软还有一个十分弱小的一个货色,相当于一整套武器库,来帮忙咱们进步交付和公布的效率,也就是Azure DevOps。这张PPT里就有十分多的Azure DevOps的资源,能够看一下: 一提到DevOps有人可能感觉这是一个job title,还有人感觉他是开发和运维的单干啊,或者说开发运维的自动化,这些都是对的,DevOps是一个很大、很宽泛的概念。 微软给DevOps下的定义:把人员、流程和产品联合起来,继续地为咱们的用户交付价值。 你能够用DevOps实现整个用户生命周期的治理,不须要去用比方JIRA去治理工作,用Jenkins配置CI/CD,再把它们组合起来,这些Azure DevOps基本上全副都曾经提供了。因为有了这种自动化的工具,咱们就不必放心公布成为破坏性的更新,因为这些公布都是自动化的,没有人工操作,只须要点点按钮,缩小了出错的可能性。对了,五人以下的团队是完全免费的! 比特熊:好!非常感谢三位老师能从不同维度,为咱们分享了丰盛的云体验。 海峰:等等比特熊,我还想总结一下,方才Alan和晓迪讲的都十分好,特地是晓迪讲的DevOps,原来叫VS Online,咱们也始终在用它,第一个起因是它的确是收费的,咱们又买了些licenses,也很便宜。大家晓得微软起家是Windows,不单单是给了大家一个工具,更是把Windows整个管理体系融在了工具里。所以我真心心愿大家,如果有机会,能够体验下VS Online,当初叫DevOps,和Azure联合得十分好。 海峰:这是对于方才技术局部,我做一个小的总结,上面就谈一下我的经验,事业方面。我学的业余其实跟计算机没有关系,是资料,化工畛域的。其实我齐全是靠自学,包含向圈内的大咖求教,读很多大咖的书。咱们过后报考大学业余,当初的互联网/编程概念都没有,只有计算机利用,具体做什么,大家也都不太分明,没有当初的岗位这么细分——前端后端、云计算等等。 当初整个环境比咱们当初要好很多,云计算曾经成为一个基础产业了,咱们守业的老本,实现幻想的间隔和土壤是十分好的。我大学的时候跟咱们的老师一起磋商,说做一个卖鲜花的网站,但发现那时候呢,第一个领取渠道解决不了,第二个基本没有物流,这些货色当初看来曾经不是问题了。 当初跟大家讲故事我会说原来的互联网,实际上是经典互联网,那一波曾经过来了,你能想到的,其实很多人都在做了。然而在一个细分畛域,还是有很多机会的,我感觉不论是在校的学生,还是咱们开发者都能够思考一下,当初很多货色到谷底了,对咱们来说也可能会有新的机会。 我一句话总结就是,作为开发者咱们能够有这样一个技术幻想,然而这个幻想是要为商业服务的。 比特熊:线上的两位老师有什么想分享的吗? Alan:那我先来咯,我的业余是跟计算机无关的了,那时候感觉学计算机,只有会写程式就好了,不必做别的事。但近几年发现,对工程师来说沟通是十分重要的一个能力,我缓缓发现,其实程序员做的事件是翻译,咱们就是把人要做的事件,翻译成机器看得懂的。 某种程度上,我应该是大家眼中比拟典型的工程师,我的日常生活其实也没什么特地的,就是每天写写文章、录一些教学影片。因为是认证讲师,所以会在一些机构做一些内训,或者是翻译文章、软件之类的。我刚毕业的时候,是web最风行的时候,可是学校齐全没有教过,所以也是要靠本人看一些书,参考一些大大的教程之类。 我蛮早就接触到MVP这个概念,MVP就是喜爱做一些分享。过后有一个Visual Studio Code的专栏,翻译都是请社群的人帮助的,我英文能力还算OK,就也帮忙翻译了一下。乏味的是,那时候负责人来到台湾,请社区做一些推广,因为我也是台湾某些社群的人,他们才发现曾经有一个叫Alan的人在做这些事件。 在疫情之前,每一年微软在美国有一个MVP大会叫Global Summit,那个负责人还邀请我,我还认为他寄错人了,因为我那时候还不是MVP。原来他认为只有MVP才会做这些事,就预设我是MVP。所以想通知大家的是,不论对什么货色有趣味,花工夫在下面,无形之中说不定就冒出来,你本人也不晓得。 比特熊:最初一位,晓迪老师! 晓迪:我跟海峰老师一样,我大学也不是学计算机的,我是学水产的,计算机也是纯正喜好。我记得我过后最早的时候,大学做了一个ASP的网站赚了六百块钱,十分十分开心。我以前感觉MVP就是十分厉害的专家,当初误打误撞本人也是了。几年之前,我是国内最早的一批的Windows Phone的开发者,写了很多Windows Phone的APP,学习的过程中遇到不会的货色,就把它写个blog收回去,大略写了得有十几二十条。 起初有一次开峰会的时候,在杭州还是哪,咱们的MVP项目组给我颁发了一个最佳吐槽奖,不是叫吐槽奖,叫最佳倡议奖,可能因为我吐槽太多了,是一个十分大的惊喜。 ...

October 19, 2021 · 1 min · jiezi

关于devops:常见开源分布式文件系统架构对比

什么是文件系统?文件系统是计算机中一个十分重要的组件,为存储设备提供统一的拜访和治理形式。在不同的操作系统中,文件系统会有一些差异,但也有一些共性几十年都没怎么变动: 数据是以文件的模式存在,提供 Open、Read、Write、Seek、Close 等API 进行拜访;文件以树形目录进行组织,提供原子的重命名(Rename)操作扭转文件或者目录的地位。文件系统提供的拜访和治理办法撑持了绝大部分的计算机利用,Unix 的“万物皆文件”的理念更是凸显了它的重要位置。文件系统的复杂性使得它的可扩展性未能跟得上互联网的高速倒退,极大简化了的对象存储及时填补了空缺得以疾速倒退起来。因为对象存储不足树状构造也不反对原子重命名操作,跟文件系统有很大的差异,本文暂不探讨。 单机文件系统的挑战绝大多数文件系统都是单机的,在单机操作系统内为一个或者多个存储设备提供拜访和治理。随着互联网的高速倒退,单机文件系统面临很多的挑战: 共享:无奈同时为散布在多个机器中的利用提供拜访,于是有了 NFS 协定,能够将单机文件系统通过网络的形式同时提供给多个机器拜访。容量:无奈提供足够空间来存储数据,数据只好扩散在多个隔离的单机文件系统里。性能:无奈满足某些利用须要十分高的读写性能要求,利用只好做逻辑拆分同时读写多个文件系统。可靠性:受限于单个机器的可靠性,机器故障可能导致数据失落。可用性:受限于单个操作系统的可用性,故障或者重启等运维操作会导致不可用。随着互联网的高速倒退,这些问题变得日益突出,涌现出了一些分布式文件系统来应答这些挑战。 上面介绍几个我理解过的分布式文件系统的根本架构,并比拟不同架构的长处和局限。 GlusterFSGlusterFS 是由美国的 Gluster 公司开发的 POSIX 分布式文件系统(以 GPL 开源),2007年公布第一个公开版本,2011年被 Redhat 收买。 它的基本思路就是通过一个无状态的中间件把多个单机文件系统交融成对立的名字空间(namespace)提供给用户。这个中间件是由一系列可叠加的转换器(Translator)实现,每个转换器解决一个问题,比方数据分布、复制、拆分、缓存、锁等等,用户能够依据具体的利用场景须要灵便配置。比方一个典型的分布式卷如下图所示: Server1 和 Server2 形成有 2 正本的 Volume0,Server3 和 Server4 形成 Volume1,它们再交融成有更大空间的分布式卷。 长处:数据文件最终以雷同的目录构造保留在单机文件系统上,不必放心 GlusterFS 的不可用导致数据失落。 没有显著的单点问题,可线性扩大。 对大量小文件的反对预计还不错。 挑战:这种构造是绝对动态的,不容易调整,也要求各个存储节点有雷同的配置,当数据或者拜访不平衡时没法进行空间或者负载调整。故障恢复能力也比拟弱,比方 Server1 故障时,Server2 上的文件就没方法在衰弱的 3 或者 4上减少拷贝保障数据牢靠。 因为不足独立的元数据服务,要求所有存储节点都会有残缺的数据目录构造,遍历目录或者做目录结构调整时须要拜访所有节点能力失去正确后果,导致整个零碎的可扩大能力无限,扩大到几十个节点时还行,很难无效地治理上百个节点。 CephFSCephFS 始于 Sage Weil 的博士论文钻研,指标是实现分布式的元数据管理以反对 EB 级别数据规模。2012年,Sage Weil 成立了 InkTank 持续反对 CephFS 的开发,于 2014年被 Redhat 收买。直到 2016 年,CephFS 才公布可用于生产环境的稳定版(CephFS 的元数据局部依然是单机的)。当初,CephFS 的分布式元数据依然不成熟。 Ceph 是一个分层的架构,底层是一个基于 CRUSH(哈希)的分布式对象存储,下层提供对象存储(RADOSGW)、块存储(RDB)和文件系统(CephFS)三个API,如下图所示: ...

September 29, 2021 · 2 min · jiezi

关于devops:Docker安装jenkins

Docker装置jenkins一、环境筹备1. 宿主机筹备 宿主机装置JDK\MAVEN\GIT\DOCKER\NPM2. 镜像筹备 jenkins/jenkins:latest-jdk8二、jenkins部署1.镜像下载docker pull jenkins/jenkins:latest-jdk8docker images | grep jenkins2.查看镜像版本docker inspect 44f8e2d8566c3.启动脚本restart.sh 挂载docker目录,容器里能够执行docker命令改用jenkins/jenkins:latest-jdk8版本镜像,能够装置gitlab hook挂载maven|npm等目录 ,jdk默认是:jdk8。否则容器内无奈应用构建命令maven要做好私服配置,仓库治理等#!/bin/bash docker stop jenkins && docker rm jenkinsdocker run -d --name jenkins \ -u root \ --privileged=true \ --restart=always \ -p 8080:8080 -p 5000:5000 \ -v /usr/local/jenkins:/var/jenkins_home \ -v /toony/server/apache-maven-3.6.3:/usr/local/maven \ -v /usr/bin/docker:/usr/bin/docker \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /etc/localtime:/etc/localtime \ -v /root/.ssh:/root/.ssh \ jenkins/jenkins:latest-jdk8 #---- jenkinsci/blueocean 默认应用jdk11版本,装置gitlab hook失败 ------ #!/bin/bash docker stop jenkins && docker rm jenkinsdocker run -d --name jenkins \ -u root \ -p 8080:8080 -p 5000:5000 \ -v /toony/jenkins/jenkins_home:/var/jenkins_home \ -v /usr/local/java/jdk1.8.0_171:/var/jenkins_home/jdk8 \ -v /toony/server/apache-maven-3.6.3:/var/jenkins_home/maven \ -v /toony/jenkins/jenkinsci:/usr/jenkinsci \ -v /usr/bin/docker:/usr/bin/docker \ -v /var/run/docker.sock:/var/run/docker.sock \ jenkinsci/blueoceandocker-compose.ymlcat > docker-compose.yml <<-EOFversion: '3'services: docker_jenkins: user: root restart: always image: jenkins/jenkins:lts container_name: jenkins ports: - 8080:8080 - 5000:5000 volumes: - /toony/jenkins/jenkins_home:/var/jenkins_home - /var/run/docker.sock:/var/run/docker.sock - /usr/bin/docker:/usr/bin/docker - /usr/local/bin/docker-compose:/usr/local/bin/docker-compose docker_nginx: restart: always image: nginx container_name: nginx ports: - 8090:80 - 80:80 - 433:433 volumes: - /toony/nginx/conf.d/:/etc/nginx/conf.d - /toony/webserver/static/jenkins/dist/dist:/usr/share/nginx/htmlEOF 4.配置插件镜像减速将url https://updates.jenkins.io/update-center.json批改为 清华大学官网镜像:https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.jsoncd /usr/local/jenkins/vim hudson.model.UpdateCenter.xml5.拜访http://http://xxx.61.41.102:8080 ...

September 24, 2021 · 2 min · jiezi

关于devops:多多益善|基于Artifactory和Buildx构建多架构Docker镜像

一、背景 在业界以后的云原生实际中,“构建一次,随处部署”的机制曾经失去了广泛利用。借助容器化和Docker,咱们能够为任何环境构建利用和服务,并在运行时再设置配置。不过,这种适应性还是有一些限度。操作系统和应用程序依然须要编译能力在特定的架构类型上执行。例如,为AMD64处理器编译的软件不能在基于ARM的机器上运行,为 Linux构建的软件也不能在Windows上运行。Docker通过反对多架构(multi-arch)镜像满足了容器利用的多CPU架构的需要。您能够为须要反对的每个架构构建独自的镜像,而后作为一个汇合将所有镜像绑定在Docker清单的列表中。而后,您能够通过其名称和标签部署生成的多架构镜像——Docker客户端将主动抉择与指标架构匹配的镜像。基于Artifactory的Docker仓库能够很不便地构建多架构镜像,而且能够像治理其余任何Docker镜像一样来治理这些多架构镜像。本文咱们将向您展现如何在开发/交付流程流程中来创立和治理多架构Docker镜像。 二、构建多架构镜像 多架构镜像 在本文的例子中,咱们须要创立一个应用程序,必须可能在Linux 操作系统下如下的两种处理器架构上运行:x86-64环境,例如 Linux 桌面; AWS EC2上基于ARM的A1 实例。 为了可能在任何一个上运行,咱们须要一个反对amd64和arm64架构的多架构镜像。 基于Buildx创立多架构镜像 首先,咱们的DockerFile必须配置为依据所需的架构来创立示例镜像,如下所示:ARG ARCH=FROM ${ARCH}debian:buster-slim RUN apt-get update \&& apt-get install - y curl \&& rm -rf /var/lib/apt/lists/*ENTRYPOINT [ “curl” ] 如果咱们应用这个DockerFile运行docker build命令,并应用--build-arg选项来设置ARCH参数,咱们能够为每个所需的架构构建一个独立的镜像。而后咱们须要构建一个独自的清单列表(应用docker manifest命令)将它们绑定到一个多架构镜像中。除此之外,还有一种更简略、更举荐的办法。应用Docker CLI的Buildx插件(参见https://docs.docker.com/build...),您能够间接创立一个多架构镜像,并利用同一条Docker CLI命令即将构建好的多架构镜像推送到Artifactory中的Docker仓库里。如下所示:$ docker buildx build \--push \--platform linux/amd64,linux/arm64 \--output=type=image,push=true,registry.insecure=true \--tag myartifactory/docker-local /multiarch-image:tag . 如果您应用的是Mac或Windows上的Docker Desktop,那么Buildx曾经随着装好了。如果您应用的是Linux,则能够从GitHub装置Buildx。(参见https://github.com/docker/buildx) Artifactory里的多架构镜像 以下是上一节创立的multiarch-image多架构镜像在Artifactory中的存储形式,该镜像存储在名为docker-local的Docker仓库中。 ► Docker清单列表Docker生成的清单列表(list.manifest.json)是多架构镜像“镜像清单的清单”,也称为“富清单”,它标识了汇合中的 Docker 镜像以及每个镜像要运行的架构(操作系统和处理器组合)。当multiarch-image利用运行时,Docker CLI将首先拉取清单列表,而后应用它来抉择拉取和部署哪个镜像,以匹配指标地的操作系统和架构。 ► 架构镜像每个被反对架构的镜像都有本人的标签,能够通过它来寻址,这个标签是Artifactory通过组合公布标签和架构名称来创立的。因为咱们的示例应用公布标签“tag”,因而架构镜像的标签是tag-linux-amd64和tag-linux-arm64。每个镜像也有本人的清单,用于标识组成它的层。 三、升级多架构镜像一旦您的多架构镜像位于Artifactory的Docker仓库并通过了测试,您就能够将该镜像升级到下一个成熟度的Docker仓库,就像其余任何类型的制品仓库一样。如下的JFrog CLI命令将咱们在docker-local仓库中创立的多架构映像升级到docker-target仓库中:$ jfrog rt docker-promote --copy \multiarch-image docker-local docker-target与任何通常的Docker镜像一样,您也能够将升级限度为镜像中的某个标签。如果您抉择在升级中重命名标签,它将为多架构镜像中的每个架构重命名。命令如下:$ jfrog rt docker-promote --copy \--source-tag “latest” --target-tag “latest-new” \multiarch-image docker-local docker-target ...

September 22, 2021 · 1 min · jiezi

关于devops:打破执行者局限技术赋能业务发展-IDCF-DevOps黑客马拉松2021上海站精彩回顾

在研发团队的日常工作中,通常有哪些起因会让业务倒退或具体工作陷入被动?总结来说,咱们认为个别会有以下几个次要问题: 管理者或骨干员工陷入到业务细节,执行者思维局限了对业务意义、指标、口头策略的思考;我的项目指标和倒退阶段定义不清,特地是在重大项目背后,投入全副资源,而业务停顿上的得胜导致资源节约;团队合作形式、开发者能力制约导致研发效力有余,整体开发效率较低;被动响应需要,始终在做救火队长的角色,导致工作节奏凌乱,团队充斥疲乏甚至狼狈感。对于研发团队,特地是大型研发团队中的管理者、研发骨干来说,跳出执行者视角,把握全局业务思维来布局工作,同时具备团队合作流水线搭建与执行者能力赋能伎俩,是越来越稀缺的职业能力特质。 DevOps黑客马拉松,由IDCF社区原创设计的学练赛一体化培训,专门帮忙优良开发者、研发团队管理者建设业务思维,用麻利与DevOps的办法、技巧、工具来优化研发工作,晋升研发效力。 36小时极客挑战,实在还原商业翻新旅程9月11-12日,IDCF DevOps黑客马拉松(上海站)圆满结束,来自华为、爱捷、西南证券、吉利汽车、太美医疗科技、中远海运、京东云、永辉科技、北京直真、美团等企业的30余名参赛者组成4支战队,历经36小时,全副胜利实现DevOps黑客马拉松挑战。 本次较量邀请精益麻利翻新专家王立杰、DevOps畛域顶级大咖徐磊、资深DevOps专家周文洋等老师负责领导教练。 DevOps黑客马拉松模仿实在业务背景,帮忙成长型企业寻找第二增长曲线,在36小时内实现守业创意-产品设计-产品开发上线-商业打算路演等多个环节,将精益守业、麻利治理、DevOps等外围常识融入到守业旅程的各个环节,现场学习,现场演练。 DevOps黑客马拉松包含7大模块: 模块一:学习端到端DevOps 5P框架,根本认知DevOps理念及办法; 模块二:商业模式翻新,通过商业模式画布,为我的项目设计一个性感的商业模式,寻找增长第二曲线;模块三:产品性能布局,通过用户画像摸索标签及痛点,利用用户故事地图梳理产品外围性能,梳理产品愿景、定义产品外围价值,构建产品MVP原型; 模块四:制订产品迭代打算,学习把握迭代指标设计、工作拆解与认领等技巧,设立物理看板并筹备执行; 模块五:现场打造继续交付流水线,搭建开发环境与分支策略,搭建继续交付流水线,梳理微服务架构并实现第一个迭代MVP版本的线上交付; 模块六:应用影响地图梳理产品冷启动布局;模块七:讲演我的项目计划并演示产品Demo,各组PK决胜。 36小时极致碰撞,战队共创效力晋升之道本期黑客马拉松由来自不同企业的参赛者组成4支参赛队伍,36小时的挑战过程中,一直碰撞思维,一起谋求极致,共创研发效力晋升之道。 在抛球游戏中,各小组通过简化流程、改进措施、了解规定、疾速迭代等形式,以晋升效率为指标赢取最终胜利,通过缓和的比拼与一直优化,“生产效率”晋升了8倍; 流水线搭建环节,3支队伍凭借优良的研发能力火速通关,最初一支战队顶住压力,以最佳流水线为指标,通力合作,一直切磋优化,最终在早晨10:38实现流水线搭建,实现效率冲破,充分体现了不轻言放弃的“黑客精力”; PLANK比赛中,现场大众选手向参赛选手发动挑战,大众选手敢于超过参赛选手,多人冲破5分钟大关,在第一名的角逐上陷入焦灼,最终握手言和,并列第一; 继续流水线搭建的加分环节,参赛选手展现出高超的技术实力,从K8S容器到Sonar代码扫描,Postman 接口测试,Selium自动化界面测试,一直尝试新的技术突破点来优化流水线;MVP设计是历届黑马中,学员认为播种最大的环节,本次黑马,将“内裤版”MVP理念贯彻全场,各团队的版本布局中均体现这一理念,精简而又有价值。特地值得一提的是,“以饭会友”主打社交的团队在线版MVP款式精美,版面简洁,博得现场参赛选手认可,并让所有学员对MVP有了更深了解; Jacky(周文洋)导师现场演示流水线搭建,用精妙的语法修复bug,用技术实力博得现场欢呼,也让参赛者对技术语法有了进一步意识;札心交友团队,个体下台,一起实现路演,分工配合,无论是最初的口号,还是过程中的内容切换,配合得浑然一体,恰到好处;最佳演讲奖获得者是一位拄着拐杖来的小姐姐,坐在椅子上解说路书,超级出彩。 在集体能力成长历程中,优良搭档之间的独特探讨、碰撞与切磋,既须要继续夯实常识体系,更须要思维与眼界的一直开辟。 36小时极限挑战,路演PK决出各项荣誉DevOps黑客马拉松挑战赛设置了最佳黑马团队、最佳流水线、最佳创意、最佳黑马精力、最佳演讲集体等多个奖项,奖项评比综合路演后果,在较量过程中,领导教练会依据各战队在每个环节的体现给予加分。 通过最终的角逐,第一组 【漫威科技】战队获得最佳黑马团队奖和最佳黑马精力奖两项大奖; 第二组【德利斯】战队,有太美医疗科技首席架构师坐镇,最先跑通流水线,获得最佳流水线奖; 第四组【轻舟科技】战队获得最佳创意奖; 来自第三组【大贫贱】战队,北京直真科技的刘丹枫取得本次黑马的最佳演讲个人奖; 太美医疗科技11位工程师,造成了一道亮丽的风景线 有过DevOps黑客马拉松的人生,才算残缺 面对疾速变动的技术与行业倒退,创业者思维越来越成为每一位职场人都须要具备的能力特质,DevOps黑客马拉松,模仿实在守业背景,36小时残缺体验守业历程,帮忙参赛者把握创业者思维,在工作中与高层同频,疾速了解业务方向。 在竞争日趋激烈的行业态势下,效力晋升成为每一家企业都须要解决的关键问题,效力晋升来自于研发流水线搭建、效力工具应用、版本布局及团队治理形式,DevOps黑客马拉松,帮忙参赛者把握精益、麻利与DevOps的思维、工具与办法,在业务实际中真正晋升研发效力。 DevOps黑客马拉松是由IDCF社区的专家老师们原创设计,并通过20余场赛事打磨迭代的培训模式,通过学练赛一体化的学习形式,招募优秀者加入较量,与参赛者独特打造一个思维碰撞、能力晋升、技能精进、见识拓展的学习环境。 咱们心愿,有更多开发者退出到DevOps黑客马拉松的挑战中,有过DevOps黑客马拉松的人生,才算残缺。 11月20-21日,IDCF DevOps(深圳站)行将召开,企业战队/集体参赛者,欢送来挑战~辨认下图二维码回复“黑马”可报名

September 17, 2021 · 1 min · jiezi

关于devops:别在自建DevOps使用云效3步搞定

别在自建DevOps?应用云效3步搞定。阿里云云效,云原生时代新DevOps平台,反对公共云、专有云和混合云多种部署状态,通过云原生新技术和研发新模式,助力翻新守业和数字化转型企业疾速实现研发麻利和组织麻利,打造“双敏”组织,实现多倍效力晋升。 创立 DevOps 我的项目点击「创立新我的项目」按钮,在「全副模板」的「产品研发」中能够找到「DevOps 我的项目」的我的项目模板。 点击抉择「DevOps 我的项目」模板,进入欠缺我的项目信息界面。该界面蕴含模板内容的概览以及我的项目的根本信息设置,设置完点击「实现创立」,一个 DevOps 我的项目就创立实现。 ① 项目名称:我的项目的名称,用于该我的项目命名② 我的项目分组:以后我的项目所属的企业内我的项目分组,可多选③ 项目编号:即工作编号的前缀,反对 2 - 6 位字母 二、权限治理我的项目角色与其余我的项目保持一致,分为 成员、管理员、拥有者。 在 我的项目中须要保障我的项目成员均有与我的项目关联的代码库、流水线的 拜访权限,这样在我的项目中能力看到关联的代码和流水线内容。可在飞流和行云对应的内容进行成员查看和权限配置。 我的项目成员有权限操作关联,但只能抉择到本人有权限的流水线、代码库。 创立代码库与代码治理 Codeup 的权限保持一致。 创立流水线与流水线 Flow 的权限保持一致。 创立或关联代码库在我的项目中集成代码库,能够查看我的项目范畴包含了哪些代码库,我的项目中代码库以后现状,同时在我的项目中间接拜访并操作代码库。 抉择我的项目面板导航栏的代码,会提醒新建代码库或关联已有代码库。 点击新建代码库,输出代码库名称、形容等待点击确认则可创立于以后我的项目关联的代码库。新建的流水线默认与我的项目关联。 如果有云效代码库中已有创立好的代码库,则点击「关联已有代码库」。在弹出的抉择框中勾选须要 关联的代码库,点击确定即可。 可关联多个代码库。 Tips:代码库会默认勾选「关联到我的项目」勾销关联后可从新关联 创立或关联流水线抉择我的项目面板导航栏的流水线,会提醒新建流水线或关联已有流水线。 点击新建开始创立流水线。抉择对应的开发语言,通过默认流水线模版或空流水线、配置代码源进行流水线的创立和配置。新建的流水线默认与我的项目关联。 须要启用代码提交触发,可查阅「代码提交触发」篇。配置实现后,代码提交就会触发流水线运行。 如果有云效流水线中已有创立好的流水线,则点击「关联已有流水线」。在弹出的抉择框中勾选须要 关联的流水线,点击确定即可。可关联多个流水线。 Tips:流水线会默认勾选「关联到我的项目」勾销关联后可从新关联 别在自建DevOps?应用云效3步搞定。阿里云云效,云原生时代新DevOps平台,反对公共云、专有云和混合云多种部署状态,通过云原生新技术和研发新模式,助力翻新守业和数字化转型企业疾速实现研发麻利和组织麻利,打造“双敏”组织,实现多倍效力晋升。

September 13, 2021 · 1 min · jiezi

关于devops:直播预告京东云DevOps与JFrog制品库的融合

企业业务体量在技术驱动下不断扩大,变更也越来越多,导致合作流程愈发简单。企业使用 DevOps进步开发品质,缩短开发生命周期已成为趋势。DevOps不仅仅是运维自动化,也是开发、测试和运维部门之间的工具链。 在落地过程中,使用DevOps在施行交付中或多或少会遇到一些问题,如果您的公司正在推动 DevOps,如果您刚好在DevOps落地过程中遇到了艰难,那么本期直播兴许刚好能解决您的疑难。 9月9日20:00,京东云联结“云筑打算”生态搭档JFrog,分享“行云”成为京东团体笼罩业务最广DevOps平台的机密,独特探讨DevOps落地中交付制品治理难题的解决之道。欢送大家扫码报名。

September 7, 2021 · 1 min · jiezi

关于devops:干掉-DevOps-IDCF

本次的分享不谈技术只谈谈想法。我从事IT行业41年了,这40年的教训并不说我就是权威、专家,但在洞察这方面做得更好些,1980年代,过后 IT 除了被倒退进去,很多的是一些我的项目的治理,实际上咱们也做了很多的我的项目,有很强的能力把握我的项目。 1990年的时候咱们开发了很多的零碎,如开发一个业余的管理系统。2000年的时候,就有麻利这一概念,从2000年开始咱们就说 DevOps。 能够看到这下面有四大转变,从传统转变到古代,通过40年的教训,我是十分认真的在思量,DevOps 对于我之前所看到的所有的改革,是一个颠覆性的改革,而且前景十分好。 大家都是 DevOps,实际上我想关注 IT 这个事件到底产生了什么?我心愿我的洞察和一些认识可能激发大家相干的灵感。比如说上图你能够看到是只鸟,你还能够从另外一个角度来看。上面的内容我会给到大家一些不同的视角去看。 干掉 DevOps 的要点: DevOps 没啥用,除非你可能在一个全局性的视线下,将其与业务建设创造性的单干。这个要点是十分重要的,我再强调一下,就是和业务独特发明价值的状况下才有用。这是十分重要的观点,这样的话 DevOps 才会有用。上面将以四块内容来论述: 探讨 DevOps向业务执行层 ”抛售” DevOps发现最单薄的环节采纳正确的态度一、探讨DevOps 盲人摸象的故事大家都晓得的。对于 DevOps 来讲,他们所摸到的都是一样就是 DevOps。如果大家在议论 DevOps 的时候须要审慎,他们说的真的是一个DevOps,还是只是一个市场行为? 咱们要真正晓得 DevOps 的价值,如果说不是盲人而是六个业务盲人和IT来摸这个大象时,他们所关注的是什么呢?是 ROI。我的想法是心愿将咱们的 DevOps 和 ROI 可能严密地联合,这其实也是一个指标。 咱们来用一个简略的框架来论述,比如说 IT 行业有行业的指引,做得更快、更便宜,而后提供更好的 IT 服务,这是 IT 人员所做的事件,他们通过这个形式来提供 IT 的服务。 同时咱们的商人有更好的信息系统信息服务,可能帮忙他们达成商业的指标,这个模型是比较简单的。商人认为是一种投资,所以他们想要投资的回报。 让咱们把它合成一下,如果咱们只看 IT 的话,它包含开发和运维,并且是十分高的精度。如果说咱们看一下商业,就是需要和应用,这是一个十分高的简略的零碎,可能具体化 IT 的要求,同时它可能应用零碎,这一点是十分高层的模式,还须要持续更具体的探讨。 接下来看一下价值链,看从一个商业的角度或者是一个信息的角度,因为商业须要业务、信息、利用和基础设施。在最开始的时候做投资的话,须要在信息科技上和解决问题上做投资。 为了做投资他们须要具体化需要,晓得要去做什么,要去研发体系等,开发须要根底,设施须要平台,须要工具来做我的项目。运维也须要平台也须要基础设施,也须要工具来提供更好的信息系统,也包含利用。 如果咱们想一想麻利的话,在价值流中麻利在哪儿呢?它其实是把信息利用和商业之间搭起了一座桥梁,这些是能够实现的指标。关键词是潜在的可实现的,它不是曾经部署过的实现的而是潜在的,须要你去部署。 当初是在生产当中的,你看一下信息体系,它其实就是运作,这一点十分好,咱们的信息体系也是在运作当中,那坏消息是咱们不能产生任何价值,因为始终到当初为止,没有人利用这些信息体系,没有人发明价值,这个畛域是咱们称之为IT信息服务流程。使用者应用这样一个零碎,心愿生成价值。他们心愿价值和商业的价值是一样的,所以咱们有一个圈,其实就是价值圈。 十分感兴趣的一点是使用者如何应用你的信息体系,你认为他们可能无效地应用信息体系吗?常常咱们的使用者并不是无效地应用信息体系,所以不会产生足够的价值。如果咱们可能想到限度实践,最单薄的点在哪里呢?你就能够去想想,投资是不是够好?是不是正确地把握了需要?能不能失常应用? 咱们遇到了一个十分乏味的观点,那就是 DevOps 的定位。个别提到 DevOps 都不太晓得所指的是什么?它怎么把研发和运维分割在一起呢?咱们应该是DevOps If,那就是基础设施的运维或者是业务的运维,我认为这是广义的定义,只是聚焦在需要、开发、基础设施、继续交付、继续部署。 然而 DevOps 能够利用在更广阔的概念上,去包含商业与 DevOps 的范畴。因为 DevOps 的准则是可能让你更好更多发明更多单干,这是 DevOps 更广阔意义上的概念。当大家谈到 DevOps 的时候,他们到底谈的广义的 DevOps,还是狭义的 DevOps 都是正确的。 ...

September 2, 2021 · 1 min · jiezi

关于devops:把效能带到游戏里仙峰红海蜕变突破之路

手游行业的蓝海与红海 传奇是2001左右的游戏产品,2014年过后国内很多大型公司在传统端游的陆地里干的热气腾腾,难以抽身。随着挪动互联网的暴发期到来,仙峰(全称:苏州仙峰网络科技股份有限公司)敏锐地察觉到一个手游的蓝海行将到来。其旗下自研产品包含《烈焰》系列等多款旗舰作,先后在市场上获得优异体现,成为传奇类手游细分畛域的景象级作品。 "过后手游市场以偏休闲类游戏为主,短少像传奇类较重度的游戏,而重度游戏可能让用户有更多的社交空间和话题,仙峰抓住了机会,推出传奇类游戏,因为竞争对手绝对较少,疾速找到了本人的市场定位。”仙峰游戏的研发总监林澄说。 生存危机再度袭来,游戏翻新速度如何赶上市场需求? 但问题也随之而来,游戏行业周期性强,中小型公司时刻都在面临生存问题。 2014年,挪动互联网开始通过了一个大量的暴增,到2017年后,挪动手机的普及率相对来说曾经到了增长下限。加之,游戏行业的排他性,一个玩家在一个固定工夫外面只可能去玩一个大型游戏,跟短视频不大一样,外部竞争更强烈。 林澄通知云效效力洞察记者:“对于传奇手游来说,游戏用户的年龄层属于30岁到50岁这个区间,游戏用户中大部分都是年老时玩过相似的游戏,心愿在手机平台找寻过来体验的玩家。新增用户较少,用户盘子稳固,如何给用户提供差异化的游戏体验,成为各家游戏厂家争取各自用户的伎俩。”仙峰:要把效力,带到游戏行业里! 在这个过程中,如何跑得更快更准?试错始终是游戏行业比拟要害的事件,而如何去进步仙峰产品整个的试错效率是目前最须要晋升优化的一个点,因为游戏行业是很难评估一个正确的方向和好的后果。当初各家游戏厂商两头的比拼分为两块,一个是对方向的判断,一个是通过阶段性的产出疾速验证这个方向是否适宜这家公司。 充沛的数据能够让业务方向的判断更加正当。所以仙峰通过破费较大的精力调研行业内一些通用的数据,包含AppAnnie一些做传统型的数据,心愿可能升高自身的老本,包含会做一些数据AB面的比拟,海内数据的比拟,接入数数科技平台,帮忙看游戏每次优化是否能进一步晋升用户体验。 人员不稳固、团队外部协调沟通不畅等问题导致开发效率低是仙峰比拟大的急需去解决的痛点。仙峰倒退阶段团队从几十人一年之内飙升到一二百个人,过后存在较大的沟通进度协调等问题,很心愿找到一款合作软件,让大团队的效率和当初小团队一样的高效。 当林澄形容到这些问题的时候,对仙峰过后面临的痛点仍旧历历在目。 内忧外患之际,一次单干的机缘,给仙峰带来了更多的可能性 2019年8月,过后,林澄参加了云效在上海举办的一次《精益麻利开发实际》的分享,培训的老师正是这次单干的负责人(阿里巴巴研发效力专家,云效效力专家团成员)洪永潮,他给了林澄一本书,是云效效力专家团负责人何勉写的,对于效力的一些根底定义。“最触动我的是说如何去顺畅高质量的交付价值。首先是顺,第二点是品质,第三是交付价值。进行交换后感觉工具背地其实更应该看重大家的一些观点和理论状况。”林澄说。比照仙峰过后的状态,组织架构调整火烧眉毛。书上提到很多观点包含如何合作、如何廓清都让林澄感觉十分合乎仙峰当下的倒退需要。 其实这些问题在业务倒退较快阶段不是很显著,起初2018、2019年当前整个行业的问题才缓缓裸露进去,过后只有个大略的概念没有方法落地,不确定办法是否正确,仙峰要去把效力,把这些货色带到游戏行业外面来。 而阿里的“双敏研发模式”在研发需要结构图中,向上是指标和业务导向的需要,能够通过麻利的组织能力实现;向下是技术和工程导向的需要,能够通过麻利的研发能力实现。 到了2020年,仙峰心愿通过更少的协同和节约晋升本身的研发效率,跟阿里建设了单干心愿可能切实解决治理问题。隔靴搔痒,初见成效:交付速度提速200% 其实咱们团队没有涉猎过游戏行业,游戏对阿里来说是一个全新的行业,同时也面临新的挑战。“对我集体来说,是须要从新去了解和摸索这样行业的,所有在理论的交付过程中,一方面赋能客户,一方面向客户学习游戏行业的一些实际和办法,同时向游戏行业的专家学习求教。”云效效力专家团成员洪永潮这样说。 “通过对仙峰研发现状的调研,发现他们基于瀑布式的开发偏多,沟通和合作还处在比拟原始的模式,暴露出需要形容不清晰,需要传递过程了解偏差大,策划案的配置文件有很多高级的谬误,开发交付的品质差,Bug数量以千为单位计算,上线周期长等问题。同时也明确了对效力晋升的诉求,冀望策划案能疾速高质量上线,满足游戏行业疾速试错的诉求。” 试点团队的调研状况通过对现状和问题进行剖析,一方面联合仙峰的冀望和诉求,另一方面联合团队的理论状况和问题,开掘起因,找到问题的基本解。 通过现状,开掘起因,找到基本解 同时造成如下的五个“建设”的施行步骤,从合作动手,往前走向指标,往后走向工程实际。 1.建设团队高效合作根底 2.建设明确的节奏进行高质量交付 3.建设以业务指标为导向的布局机制 4.建设度量反馈的继续改良机制 5.建设跨团队合作机制和为规模化做筹备 仙峰和阿里的单干渐入佳境,也获得一些初步成绩。 突破了经营组、项目组、平台组、运维组的部门竖井,整体的合作沟通老本显著降落,效率明显提高。 跨部门的需要廓清更容易,需要提测后,功能性问题数量升高一半以上,从之前的40%-50%升高到20%。同时需要队列实现了依照优先级排期,造成周期性的迭代实际。 “入场前,仙峰策划案的交付周期在6周以上,计划落地后交付周期会缩短到4周,平台组的交付周期已缩短到2周。” 继续摸索研发效力晋升实际:OKR落地和数据效力洞察 继续地晋升研发效力,是一个艰巨的、长期的过程。过程中洪永潮与仙峰还进行了三个关键问题的深层次摸索与实际。 第一个是摸索和梳理策划案业务流程相干的事件风暴,因为策划案的问题层出不清,有策划案的流程不顺畅,要害业务流程的缺失和冗余,异样环节思考不全面,设计缺点多,上下文容易脱漏,其中某项业务采纳用事件风暴的形式进行业务流程的梳理,让策划案的流程更加顺畅,设计缺点更容易被发现,性能思考更加全面,业务布局和拆分容易。 用事件风暴梳理业务流程 第二个是指标和策略对齐,梳理业务流程时,很天然会问到为什么要这样设计?流程还能够优化吗?流程还能够更简略吗?有没有更好的业务流程?当问这些问题的背地始终有指标和策略在牵引着,但这个在项目组没有清晰的出现和同步进去,所以联结发行、经营和策动同学一起梳理该业务的指标、策动和验证形式,让整个我的项目的打法明确和清晰。 对齐指标、策略、验证形式和实现工夫理论落地到时候,发现只是对齐某个我的项目或业务的指标与策略是不够,还须要对齐各业务之间和公司的指标,于是进行了OKR的培训、设定和施行。整个公司的指标能够透明化的上传下达,让大家指标感更明确和清晰。 指标设定,组织对齐和评估反馈第三个是中后盾和SDK的工程实际,为了更好的撑持公司游戏业务的倒退,须要进一步缩短经营需要交付时长和晋升公布成功率,工程这块落地了分得清,看得见,改得了,高可用和高性能的5个方面,别离是:• 分得清:各个服务权责明确、接口清晰 • 看得见:服务情况、线上问题、利用性能可观测、可追踪 • 改得了:服务公布对用户无影响、有问题能疾速回滚,缩短公布工夫,提• 升公布成功率 高可用:无单点问题(过程单点、主机单点、IP单点、az/region单点等) • 高性能:可程度扩大、有性能基线、指标性能 中后盾服务划分实施方案办法的赋能和工具的撑持,实现交付周期缩短一半 在阿里的合作平台上,能够看到其中一个团队的需要交付周期的85%控制线在21天,这个比刚入场时的需要交付周期时间简直缩短了一半。 一个试点团队的需要交付周期管制图大家的意识建设起来了,观点上也有扭转。包含一些数据的回顾、推动OKR等。“当合作畛域下面的事件捋顺了当前,对于指标的需要和对后果的统一评判的要求这个需要天然起来了。阿里整体的治理和营销想法是对仙峰最大的帮忙,包含用户思维、工作形式办法等。将来的话仙峰心愿跟阿里具体探讨一下,包含一些DevOps机制,放慢整个企业在工程畛域上合作等。” 继续晋升研发效力,一方面须要办法的赋能,另一方面须要研发工具的撑持,这两者相辅相成,独特打造组织的麻利能力和研发的麻利能力,并助力仙峰在数字化时代走向双敏,最终晋升了公司的外围竞争力。 “接下来,仙峰仍会去服务这波咱们相熟的用户,而后去做一些根底的冲破和翻新,一直开掘用户对游戏的激情和激动,晋升企业效率跟迷信的经营方式。”仙峰游戏的CEO易总对将来的单干充斥期待。 欢送大家应用云效,云原生时代新DevOps平台,通过云原生新技术和研发新模式,大幅晋升研发效率。

August 31, 2021 · 1 min · jiezi

关于devops:Jira-Issue类型和工作流最佳实践

1.概述Jira Issue分类和工作流是应用Jira治理事务的根底,并且Jira工作流波及度量相干指标的可实现性。因为公司外部的我的项目千差万别,每个我的项目团队的治理形式也千差万别。因而希图通过设计一套工作流满足所有人的需要根本是不事实的。希图这样做的结果,一个是设计出一个巨简单无比的工作流,被所有人吐槽。另一个就是利用势力压迫所有人应用一个规范的工作流,满足不了个性化的需要。这两种计划都算不上最佳的实际计划。一种可参考的计划就是定义出工作流中每个结点,让所有人在这其中进行抉择结点搭建本人的工作流。这样兼顾了标准化和灵活性。如何设计出能笼罩所有的人需要的结点,而不会呈现脱漏。 辨认我的项目中流程(项目管理、业务、产品、开发、测试、运维),并定义流程里的角色(XX经理、XX人员)。定义每个角色可能进行的动作。这样就能定义出一份较完整的结点列表供不同我的项目团队进行配置应用。 2.Jira Issue类型2.1.瀑布式开发流程用户故事有代码交付的需要工作非代码交付的工作项都能够归于工作缺点测试发现的问题故障线上零碎呈现的问题2.2.并行合作开发流程用户故事:多角色合作并行处理时,能够采纳子故事的形式实现。 ① 业务子故事 ② 需要子故事 ③ 开发子故事 ④ 测试子故事 ⑤ 运维子故事工作 ① 子工作缺点故障3.工作流节点命名标准节点命名标准:角色+动作 3.1.用户故事节点列表规范的瀑布的软件流程能够应用这个流程。故障能够复用这个工作流。 用户故事规范的工作流:PROJECTID-USERSTORY-WORKFLOW 3.2.工作节点列表如果应用并行或者多人协同工作的用户故事、需要子故事、开发子故事、开发子故事、测试子故事、运维子故事、子工作能够复用这个工作流。 工作规范的工作流:PROJECTID-TASK-WORKFLOW 3.3.缺点因为bug有规范的流程,故采纳规范的bug解决流程。缺点规范的工作流:PROJECTID-BUG-WORKFLOW 4.工作流命名标准工作流命名标准:我的项目关键字-Issue类型-WORKFLOW。例如:PROJECTID-USERSTROY-WORKFLOW。

August 24, 2021 · 1 min · jiezi

关于devops:自动产出changelog第三节releaseit与Drone持续部署工具结合使用

背景通过《主动产出changelog-第一节:标准提交代码》与《主动产出changelog-第二节:主动产出》两节内容的记录后,日志能实现一键产出。在小我的项目中未接入继续部署的,本地跑release-it命令就能简略实现版本标记、产出日志、推送git与npm的流程,可说是一步到位。公司我的项目基于Drone继续部署工具的研发流程下,须要将下面提及的步骤联合到继续部署工具进行。 简略阐明一下我当初基于Drone打造的开发流程: 分支状况: master分支作为代码汇总的分支,PR/MR后触发继续部署主动部署到测试服务。production分支作为生产分支,push代码后触发继续部署主动部署到线上服务。研发至公布操作过程: fork一份代码至本人名下,而后本地开发。实现开发需提测时,发动PR/MR推到主仓库,组长或组员code review通过后合并至主仓master分支合并master至production,更新日志与版本号后提交production分支进行公布操作在下面流程中人工更新版本的环节在多人合作的过程中会存在比拟大误操作危险,所以才打算用工具实现自动更新版本的工作。这就是《主动产出changelog》文章三节内容的最终目标。 本文提及的内容与我司当初应用Drone继续交付工具与工作流程高度绑定不倡议生吞活剥,整体参考思路大致相同倡议借鉴学习。上面解说继续部署中release-it在继续部署工具Drone应用的细节局部。 联合应用的细节 继续部署中的流程分为:拉取仓库、构建代码、部署推送,三个局部。当初须要在这个流程中减少“版本更新”这一环节,上面是drone部署配置参考例子: kind: pipelinename: releasessteps:- name: release image: tarampampam/node:12.13-alpine environment: SSH_KEY: from_secret: ssh_key commands: - GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i $SSH_KEY" - git config --global user.email "in_boot@uxfeel.com" - git config --global user.name "in_boot" - npm ci - npm run build - npm run test:unit - npm run release -- --ci --no-git.requireUpstream --git.pushRepo=origin- name: release2npm image: plugins/npm settings: username: in_boot email: in_boot@uxfeel.com password: from_secret: npm_password registry: http://self.uxfeel.com/trigger: branch: - production event: - push代码尽管是简略几行,背地细节及思路却比拟繁冗的,须要具体地提及一下。 ...

August 24, 2021 · 1 min · jiezi

关于devops:CICDgitlabjenkinssonarqube实现自动构建代码自动检测

1 前提条件1、须要装置gitlab、jenkins、sonarqube; 2、gitlab须要能拜访jenkins地址,网络是通的,因为须要通过gitlab推送事件到jenkins机器; 3、gitlab我的项目,须要有主程序员及以上权限。 2 整体思路1、当有代码push到代码仓库的时候,gitlab是晓得的,gitlab检测到有代码push的时候,执行一个钩子(gitlab上叫hook),能够了解为触发一个推送工夫,推送到jenkins; 2、jenkins 检测到这个事件之后,主动构建(不必手动了); 3、jenkins能够配置构建后动作,配置构建后主动执行sonarqube检测。至此,实现主动构建+自动检测的全过程。 3 第一步:配置密钥对应用jenkins账号邮箱,生成密钥对。 ssh-keygen -t rsa -C "邮箱地址" -b 40961、私钥,配置在jenkins 的我的项目配置中,上面会说配置在哪。 2、公钥,配置在gitlab的集体设置中,菜单:“SSH密钥“,如下图所示。 4 配置jenkins和sonarqube1、在jenkins中创立一个我的项目; 2、关上“源码治理”,配置gitlab我的项目ssh地址,配置分支名,如下图2所示。 3、增加账号,类型抉择“SSH username with private key“,上面减少下面生成的jenkins私钥。 3、设置触发器,选中“Build when a change is pushed to GitLab. GitLab webhook”,记住我的项目地址(记住1) 4、抉择上面的高级,点击生成,生成secret token,记住这个token(记住2)。 5、配置构建后动作——sonarqube扫描 一个例子 sonar.projectKey=project-demosonar.projectName=project-demosonar.projectVersion=1.0 sonar.language=java sonar.java.binaries=target/classessonar.sources=src/main/java 5 配置gitlab webhook如下图所示,在我的项目中,抉择设置——》集成——》增加钩子。 填入url和secret token(jenkins配置中的两个记住),勾销选中“SSL证书验证“ 测试,点击 test——》push event 。 阐明:如果执行测试,出错:Hook executin fail: execution expired,那么有可能是gitlab、和jenkins网络不通。 如果测试通过,会返回:Hook executed successfully: HTTP 200。 ...

August 23, 2021 · 1 min · jiezi

关于devops:DevOps如何攻克研发流程六大痛点

现在,各大企业都将技术研发核心定位于参加企业倒退策略、重大的新产品、新技术的决策,是整个企业技术治理、决策的龙头和外围。而 DevOps 作为软件工程畛域目前大家公认绝对更好的一种工作形式和 IT 组织文化,近两年备受企业关注与尝试。明天,就跟大家聊聊企业研发过程治理的6个痛点,和如何通过落地 DevOps 平台及解决方案解决这些问题的。 痛点1需要开发过程合作难 很多团队的合作模式依然是传统的 CMM 类的思路,概括一下就是“重型文档、低频交换”。日常的工作组织模式则形形色色,并且有很多用户一开始其实并没有做到所谓规范的“瀑布”,或者“麻利”。他们可能十分在意文档的交接,但又很难做到事无巨细的文档,甚至文档后补也是常事;可能有2-4周一个周期的迭代或者上线窗口,却未必能做到在约定周期内将内容交付;可能排到每个工程师手里的工作除了新性能开发,还会有很多缺点修复或者其余各种工作,而这些工作又未必会被认可投入工时;还有不同我的项目的工作工作较之而来,让人不免出错,以至于可能有时候都会遗记本人已经投入工时做的工作。所以,如何帮忙工程师和工程师主管清晰、无效地解决集体和团队工作排程问题是在需要开发合作过程中的第一个问题,并且这其实也是对项目组和工程师的一种爱护。 解决方案 通过落地 DevOps 平台及解决方案,能够以“工作项(需要/缺点/工作等)”为治理对象,以“版本”、“迭代”为治理单元,以看板、甘特图等为工具,将团队协同工作疾速组织起来,建设可视化的治理形式,并且与上游的业务需要、下右的代码等关联起来。 痛点2研发测试过程迟缓 管理者总是心愿研发过程快一点,更快一点,心愿尽快的交付业务价值。而研发团队此时便须要思考工夫到底要如何调配?哪局部花掉的工夫是能够节省下来的?对于一个生产级的代码工程(Project)来说,除了敲代码、思考、重构花掉的工夫之外,其实有很大一部分是工程构建和测试工夫。让咱们把视角从某个工程师的身上转移到整个研发团队,如果每个人每天在工程构建和调试上花2个小时,那一个10人的小型团队一天的开销就是20小时,也就是超过2个工作日的工夫,那如果周期放到一个月呢?而现代化的软件开发,通过 DevOps 实际,能够将这部分开销大大降低。通过工具链的构建升高工程师的重复劳动工夫,并自动化测试来疾速回归并保障构建的品质基准。 解决方案 通过落地 DevOps 平台及解决方案,大幅度缩小团队花在工程构建、回归测试方面破费的工夫。并且通过每日构建、特定分支合并构建等实际模式,防止在最终集成测试的时候才发现构建过程中的问题。 痛点3代码管理混乱 通过观察,有大量的研发型组织,在导入 DevOps 之前,甚至都没有一个组织级明确的代码分支管理策略。有的组织在应用 SVN 时,仅仅是把 SCM 工具用来打 Tag ;有的组织尽管曾经开始应用 Git ,却没有利用好现代化 SCM 工具便捷弱小的分支治理能力;还有的组织在应用 Git 时,分支间的合并关系凌乱。代码是软件研发的外围产出物,是软件制品资产的根底。很难想像,凌乱的代码管理模式中隐含着怎么技术危险。除了规范性自身的问题之外,咱们常常还会想看某个版本到底有哪些需要/工作内容,这些内容又对应了哪些代码的变更。亦或某些代码的变更是对应了哪些需要或者哪个版本,这些都是在代码治理畛域应该被关注的内容。 解决方案 通过落地 DevOps 平台及解决方案,能够联合不同的 SCM 工具,指定组织级的代码分支管理策略,规范化代码治理流程并升高代码背地隐含的危险。 痛点4手工利用公布 国内很多用户的生产公布都是定期公布窗口,比方银行和运营商,一到周四或周五发版日,为了不影响业务,往往是深夜才开始发版,整个公布过程都是手工操作,是否能一次性胜利,除了软件自身的品质外,全靠具体工程师是否能全神贯注,打起十二分精力来应答每一个操作,所以命令级的公布部署手册必不可少。而有些大型行业软件服务厂商的解决方案是,给本人的简单业务零碎嵌入一个自研的小型公布零碎,以升高本身的公布难度。而这对于甲方客户来说,就是银弹了吗?你会发现可能一家银行的公布,不同的业务零碎、厂商,会有不同的公布零碎。嵌入自研的小型公布零碎的后果很有可能就是为了解决一个问题,却造成了更多的问题。 解决方案 通过落地 DevOps 平台及解决方案,能够建设对立的公布体系,并且灵便应答生产和非生产的公布场景。对于生产类公布场景,通过上线申请单、环境资源筹备、公布流程编排等能力,代替原有人工公布的形式,升高相干工程师的操作危险与工作压力,将公布过程从“黑盒”变为“白盒”,可反复、可验证。对于非生产类的公布场景,除了生产级的公布流程编排外,还能够通过流水线集成、容器云平台对接等形式,疾速公布,缩小等待时间,提速研发过程。 痛点5研发过程改良不足抓手 研发过程如何改良,是 CIO 和研发负责人永远关注的问题之一。软件行业通过多年的倒退,其自身的复杂性和工程治理的的复杂性曾经失去大家广泛认可。在找到银弹之前,咱们须要一个抓手,通过改良和优化软件研发过程和流程,来晋升研发的品质和效率。在传统软件开发开发的场景中,这只能靠专家的常识积攒和责任心。咱们可能会看到一个团队中可能会有一个“高手”,每天疲于奔命在解决各种技术问题;也可能会看到组织成立了一个“架构部”,但架构部肯定能解决具体项目组的难处吗?还是只是做口头的架构评审?所以如何让专家们的常识传递到整个团队?如何将行业最佳实际嵌入到组织的软件研发过程当中?如何去察看咱们到底有多少问题?如何判断从哪里开始改良?这些都是过程改良中的外围。 解决方案 要想解开这些难题,一方面须要组织建设上的改良,另一方面很重要也能够很快看到成果的办法就是搭建工具链并建设 DevOps 平台。通过搭建工具链,让研发过程中的各种产出物数据(流水线、代码、制品、测试文件等)积淀下来;而 DevOps 平台的建设,更是能在此基础上,将过程数据积淀下来的同时,将沉积在各个工具中的数据整合、出现进去,让“数据驱动研发过程改良”成为可能。 痛点6组织级研发治理标准难以落地 在推广组织级研发治理规定的时候,经常因为市场压力、打算工夫限度、贵广执行难度等等各种盘根错节的起因而很难落地,最初导致研发治理标准成为一纸空文。不论是需要的剖析流程/工具、代码的提交与合并策略,制品库的命名标准等等,研发的整个过程遍布了咱们“心愿标准而又难以标准”的状况。而在标准的另一面,研发团队也倍感焦虑,为什么在继续加班赶工的状况下组织依然给咱们减少额定的工作量?在标准落地过程中发现问题点并反馈时如何做到在实在精确的同时更容易被组织承受? 解决方案 通过落地 DevOps 平台及解决方案,一方面能够将标准内嵌的零碎和团队的日常工作中,另一方面还能够通过平台对研发过程和工具链过程数据的收集整合,将实在、清晰、无效的数据反馈给研发团队和组织管理者,通过继续的建设优化,造成可落地的、一直迭代倒退的组织IT研发治理标准。 对于博云BeyondDevOps平台:博云BeyondDevOps提供从“需要->开发->测试->公布->运维->经营”端到端的开发经营一体化平台解决方案,笼罩项目管理、研发治理、测试治理和运行治理的协同服务和研发工具撑持,将线下 IT 生产过程转变为线上高度自动化、可视化的 IT 生产线,晋升产品研发效率,疾速响应业务需要,保障工作品质,并通过度量剖析、危险预判,继续晋升 IT 经营能力。作为率先通过中国信通院首批 DevOps 评估的厂商之一,博云 BeyondDevOps 平台取得 DevOps 利用开发域的最高级别——先进级认证。BeyondDevOps 的集成开发环境、代码托管、代码评审、编译构建、流水线、部署公布多项 DevOps 外围工具能力达到国内领先水平。 ...

August 20, 2021 · 1 min · jiezi

关于devops:Jira介绍

1.1.概述Jira是Altassian公司出品的我的项目与事务跟踪工具,被广泛应用于缺点跟踪、客户服务、需要收集、流程审批、工作跟踪、我的项目跟踪和麻利治理等工作畛域。Jira具备配置灵便、性能全面、部署简略、扩大丰盛等特点。Jira官网:https://www.atlassian.com/sof... 1.2.Jira界面 Jira最重要的几个概念和性能,仪表盘、我的项目、问题、面板。我的项目里重要的概念和内容。面板、Sprint、问题。我的项目设置模块,进行我的项目的相干配置。零碎设置模块。进行零碎的相干配置。1.3.Jira性能介绍1.3.1.DashboardJira提供数据大屏的性能,帮忙管理人员提供剖析展现性能,发现我的项目进行过程中可能存在的问题,找到改良的中央。能够通过简略的配置就能够提取Jira的数据生成图表,并进行展现。配置数据大屏的性能很简略。只须要点击“增加小程序”,抉择想要展现的图标并进行相干配置。增加小程序的步骤如下: 点击“增加小程序”抉择小程序配置小程序(配置筛选器,筛选出想要展现的数据)点击“增加小程序”抉择小程序配置小程序(配置筛选器,筛选出想要展现的数据)1.3.2.我的项目Jira中的我的项目绝对简略,只须要在创立我的项目时抉择好我的项目类型。我的项目的类型决定了项目管理过程中采纳哪些概念。个别的开发我的项目倡议抉择software“Scrum开发方法”就能够了。创立我的项目时也能够抉择“创立与共享配置”选项,这个选项在公司中尤为起作用。系统配置管理员只须要建一个合乎公司标准的我的项目模板,其余我的项目就会复用相干的我的项目配置,能大大加重我的项目配置的性能量。 1.3.3.问题问题是Jira里最重要的概念。它的英文是Issue,也就是Jira介绍里所说的事务,对应咱们日常项目管理过程中的各种工作项。而在问题里最重要的是问题的类型,把问题类型定义好,咱们应用Jira治理我的项目就迈出要害的一部。Jira默认提供了Epic、工作、子工作、故事、故障等根本问题类型。项目组须要依据理论状况来定义问题类型。将项目管理过程中各种工作项进行分类。将分好的类和问题的类型对应起来。 1.3.4.面板面板蕴含2种类型,“Scrum”类型和“看板”类型。2者最大的区别是是否有打算。“Scrum”有打算,个别会设置2周为1个sprint,纳入到sprint里的问题被投入人力全力解决。没有纳入sprint的期待下一个sprint再解决。通过较短的sprint周期,兼顾了计划性和灵活性。“看板”没有打算,新增的问题可随便调整优先级。比拟适宜“领导说了算的”治理模型。问题的优先级可随时调整,打算可随时调整的治理状况。比拟适宜目前大部分公司的治理状况。尽管如此,个别状况下都是用着“Scrum”的名义,干着“看板”的事。因为既要显得有打算,又要“说了算”,其实“看板”也是一种治理形式,大可不必这样。 Scrum的看板会有Backlog和sprint 2个概念。新建的问题会先进入Backlog(工作池),纳入到冲刺打算的问题会进入“sprint”中。 “sprint”的面板,能够不便跟踪sprint里各个问题的停顿状况。 1.3.5.我的项目设置我的项目设置里蕴含了我的项目所有的配置内容。个别状况下,次要会应用到“问题类型”、“工作流”、“界面”、“用户和角色”、“权限”、“告诉”等配置项。问题类型:配置Jira里问题的类型。 工作流:为不同类型的问题,配置不同的工作流程。界面:为不同类型的问题,配置不同的展现界面。用户和角色:给我的项目里人员配置不同的角色。例如管理员、开发人员、测试人员等。权限:为不同人员,不同角色配置不同的权限。告诉:当问题内容产生变更时,通过配置,告诉不同的人员和角色。1.3.6.零碎设置提供零碎级别的设置,只能由系统管理员进行操作。提供应用程序,我的项目,问题、治理利用,用户治理,最新降级报告,零碎的配置。其中罕用的由我的项目、问题、治理利用(治理插件)、用户治理。提供比我的项目设置更高级别的配置。

August 20, 2021 · 1 min · jiezi

关于devops:DevOps面面观-IDCF

源于读了《凤凰我的项目:一个IT运维的传奇故事》一书(感激徐磊同学的举荐),这本小说体零打碎敲的书,浏览感触十分好,提笔想做读书笔记却有些犯难,小说貌似只有写读后感的;恰好随后给共事做过两次DevOps的介绍,伺机整顿了一下思路,将本人对DevOps方方面面的了解,最终出现为这篇文档,作为阶段性的总结。 什么是DevOps?DevOps不只是开发与运维的问题从大处着眼从小处下手通过加大部署/公布频度来撬动整个交付过程自动化、标准化、配置化DevOps实际DevOps与云DevOps与精益、麻利三步工作法一、以下问题有没有解?“疾速将产品推向市场” 与 “提供稳固、平安并牢靠的IT服务” 是否能够兼得?用更少的资源实现更多的业绩,既要放弃竞争力,又要削减老本;如何解决工作交接呈现的问题,例如业务与开发,开发与运维之间;运维人员是否和其他人一样,失常上下班,而不必在夜里或者周末加班?二、什么是DevOps? 七嘴八舌WikiPedia上说:”DevOps是软件开发、运维和质量保证三个部门之间的沟通、合作和集成所采纳的流程、办法和体系的一个汇合。它是人们为了及时生产软件产品或服务,以满足某个业务指标,对开发与运维之间相互依存关系的一种新的了解。“ 百度百科说:“DevOps(英文Development和Operations的组合)是一组过程、办法与零碎的统称,用于促成开发(应用程序/软件工程)、技术经营 和品质保障(QA)部门之间的沟通、合作与整合。它的呈现是因为软件行业日益清晰地意识到:为了按时交付软件产品和服务,开发和经营工作必须严密单干。” IBM这样说:DevOps是企业必备的继续交付能力,通过软件驱动的翻新,保障组织抓住市场机会,同时缩小反馈到客户的工夫。 三、DevOps不只是开发与运维的问题一般而言,开发与运维有着不同的文化;开发部门的驱动力通常是“频繁交付新个性”,而运维部门则更关注IT服务的可靠性和IT老本投入的效率,升高危险。两者指标的不匹配,在开发与运维部门之间造成了鸿沟,从而减慢了IT交付业务价值的速度。运维从维稳登程,天然心愿生产零碎部署上线次数越少越好,而上线频度升高,对开发人员是一个负激励:反正我公布的版本也不会上线,反正我再踊跃也不能实时的体现进去,团队积极性和人员士气都会受到打击。 与此同时,业务部门则心愿业务需要尽快的推向市场,而维稳的要求导致价值交付用户的速度被延缓,价值无奈迅速失去反馈验证。 当公布列车变成3个月一趟车次时,业务人员习惯于本人的需要无奈疾速失去满足,能想出的的办法就是把所有的业务需要都设置成最高优先级,去抢占公布窗口。所有人都这样想这样做,拥挤就此产生,真正高价值的需要无奈失去疾速交付。(试想,如果每天有十次公布,大家还会拼得头破血流去抢一个公布窗口么?) 上线频度低的另一个副作用是,单次上线中蕴含的变更规模变大,危险也随之减少。事实上,缩小上线次数不仅不会升高危险,反而让每一次上线都变得像一个火药桶,危机四伏。 四、从大处着眼究其基本,DevOps目标是晋升业务交付能力:如何疾速的交付想法;如何让客户进行尝试(从而获取反馈);如何疾速响应客户反馈; DevOps不应该只是IT外部的几个部门玩的游戏。必须跳出IT的角度,端到端(业务端到客户端)剖析,能力弄清公司须要依附IT的哪些工作来撑持业务指标,撑持企业策略 ,从而实现更残缺、真正的DevOps。 须要将IT变成一种能力,融入公司的日常运作中,融入业务流动中。在快鱼吃慢鱼的时代,须要疾速试错,一直整合来自市场的反馈。 所以最终,DevOps是一个端到端的问题,是产品管理部、开发部、测试部、IT运维部、信息安全部协同工作,独特反对。 DevOps尝试建设一个业务价值交付管道,业务布局、需要梳理、打算、开发、构建、测试、部署、运维、监控 ,在此交付过程中波及到的部门/团队、过程、零碎、办法都归属于DevOps关怀的内容。 五、从小处下手了解了DevOps是一个端到端的过程,整个交付链条波及太多的畛域,问题也层出不穷,无从下嘴。实际操作中,须要有一个切入点。 DevOps的思维以精益与麻利为外围,通过裸露问题,解决问题,从而实现继续改良。从精益的角度看,在代码投产之前,实际上未产生任何价值,都只是半成品。 要限度半成品,即在制品(WIP)数量,让其尽快流过生产线,让投入产生交付价值。 DevOps是一个简单问题,咱们却心愿能够把一个简单的问题简单化:正如装修时通过加压查看管道是否泄露,是否有阻塞;咱们也通过加压的形式来裸露软件交付管道的问题。 如何加压?以终为始,咱们抉择业务价值交付的那个点,也就是部署与公布来对整个交付管道进行加压。 能够简略的问本人一个问题:“能不能一天部署10次?”如果没有方法?那么起因何在?流程不标准?自动化不够?沟通导致效率低下?过程无奈复用?环境差别导致回归出错?逐个的裸露问题,解决问题,交付能力天然晋升。 须要留神的是,依据《凤凰我的项目》中提到的TOC束缚实践(Theory of Constraints),在瓶颈之外的任何中央做出的改良都是假象,在瓶颈之后做的任何改良都是徒劳的,因为只能干等着瓶颈把工作传送过去,而在瓶颈之前做的任何改良则只会导致瓶颈处沉积更多的库存。所以如何辨认真正的瓶颈变得尤为重要,在发现问题之后多问几个为什么,力求找到本源起因。 DevOps的由来Flickr公司的约翰.阿尔斯帕瓦和保罗.哈蒙德在2009年Velocity技术大会对于开发速率的一场演讲,“一天十次部署”,是2009年前后衰亡的DevOps静止的一部分,提倡开发和IT运维通力协作,在实现高频率部署的同时,进步生产环境的可靠性、稳定性、灵敏性和安全性。2009年一天十次部署就算很快了,但当初只能算平均水平,2012年亚马逊公司发表,他们均匀每天能发展23000个部署。 Wikipedia上说,有以下几方面因素可能促使一个组织引入DevOps: 应用麻利或其余软件开发过程与办法业务负责人要求放慢产品交付的速率 (新兴技术趋势,例如云计算、挪动利用、大数据和社交媒体)虚拟化和云计算基础设施(可能来自外部或内部供应商)日益广泛数据中心自动化技术和配置管 理工具的遍及传统的治理形式导致“烟囱式自动化”,从而造成开发与运维之间的鸿沟六、通过加大部署/公布频度来撬动整个交付过程以利用部署自动化作为切入点,由部署自动化,往前倒逼测试自动化、构建自动化;进一步往前,配置管理、变更治理是根底要求;再往前,业务需要与麻利打算同步关联,通过短周期迭代交付与反馈,增强业务与开发的合作沟通; 同样的,往后端与运维连接,更小、更频繁的变更,须要让开发人员更多地管制生产环境,更多地以应用程序为核心来了解基础设施;须要定义简洁明了的流程,尽可能地自动化;从而在实现高频率部署的同时,进步生产环境的可适应性,与此同时,可靠性、稳定性、弹性和安全性也同时晋升; 由此也促成了开发与运维的合作,通过一直缩减批量规模,实现疾速工作流,确保了部署环境时刻准备就绪,按需投产。频繁的公布、意味着每次公布蕴含的变动更少,每次部署不会对生产零碎造成微小影响,应用程序会以平滑的速率逐步成长。逐渐协调和弥合开发与运维之间的技能鸿沟和沟通鸿沟。 七、DevOps要实现:自动化、标准化、配置化自动化:全面自动化,构建、部署、测试、降级、扩大、保护、数据卫生、监测、平安和策略管理。通过自动化,倒逼团队高效沟通,倒逼流程标准;自动化伎俩确保部署工作的可重复性、缩小部署出错的可能性。标准化:(流程,环境,配置)根底环境标准化,运行环境标准化,应用环境标准化/多样化 ;配置化:通过配置,尽量避免代码,通过性能开关或者参数设置,来反对A/B testing、灰度公布;八、DevOps实际不做什么比做什么更重要:相比起向零碎中投入更多的工作,将无用的工作剔出零碎更为重要;无用的工作,无用的我的项目,无用的产品;排优先级,哪些是重要的工作;运维参加研发评审:常见的景象是,运维人员很少被邀请参加架构决策或代码评审,开发代码是否会影响运维环境后期无人知晓,须要让运维人员参加架构评审,从运维角度提出对系统的要求;非功能性需要同样重要:偿还技术上的债权。每个人都像器重功能性要求一样器重非功能性要求QoS(品质,稳定性,可维护性,持续性,可扩展性,可管理性,安全性,可操作性),非功能性需要对于实现业务指标等同重要。要把非功能性需要设计到产品当中。整体合作:产品所有者,开发部,QA,IT运维部以及信息安全部通力协作,帮忙彼此乃至整个企业取得胜利。品质为先:上游团队不再给上游团队造成麻烦,开发部将20%的工夫用于帮忙确保工作顺利的通过整个价值流,放慢自动化测试,改良部署基础架构,并确保所有应用程序建设有用的产品遥测;基础架构即代码(Infrastructure as a Code):把创立和部署流程自动化,把基础架构当成代码一样看待;各套环境之间,代码版本、运行时、环境配置须要匹配;须要将根底环境配置化、版本化治理;运维服务化:DevOps会让开发部门承当更多的代码部署和维持服务水平的责任。要求把许多IT运维工作转变为自助服务。版本化所有(Versionlize Everything):应该把所有货色都进行版本控制,不只是代码,而是创立环境所需的每一样货色。ITIL:为了适应DevOps更短的交付周期和更高的部署频率,ITIL流程的很多方面都须要自动化,特地是变更、配置和公布流程等。云计算:无效的利用云技术,能够为开发和测试人员动静设置基础架构资源,疾速取得测试环境;针对类生产零碎进行开发和测试 (环境的标准化),利用可反复的牢靠流程进行部署,监控并验证运维品质;放大反馈回路:疾速反馈回路,避免问题代码进入生产环节,并且让代码可能迅速部署投产,从而迅速发现并修复任何产品问题。(编写代码时,单元测试、集成测试、验收测试始终在类生产环境运行,一直确认,代码和环境奖会依照事后设定的运行,并且总是处于可部署状态) 九、DevOps与云DevOps要反对云,虚拟化与云技术能够带来DevOps要求的标准化以及自动化; 环境标准化,无论是基础设施还是运行时环境,并把这些环境投入开发、QA和IT运维的日常应用,就能打消大部分在部署流程中因为差别而导致的问题。不仅应该拿出可部署的代码,还应该领有部署这些代码的确切环境,并在版本控制中一并管制与查看。 混合云下的DevOps诉求:在云的场景下,如何利用虚拟化、容器等减速环境的创立以及标准化,如何通过自动化的形式放慢环境搭建;如何在On-Prem、公有云、私有云,不同厂商不同类型的云的混合模式下,对立流程,对立DevOps的用户感触; 同时,由应用层的自动化部署,同样能够发现Infrastructure层, Runtime层的问题,虚拟化与云的技术也与DevOps相辅相成,井水不犯河水。 十、DevOps与精益、麻利DevOps是基于麻利与精益准则的办法。DevOps是软件开发生命周期(SDLC)从瀑布式到麻利再到精益的倒退。 DevOps超过了麻利,它的关注点是从SDLC中移除节约。通常状况下,发现节约或者瓶颈的模式包含:不统一的环境,人工的构建和部署流程,差的品质,IT部门之间短少沟通和了解,频繁的中断和期待,局部实现的工作,额定的性能,工作切换等。 DevOps强调流水线,交付管道,与传统生产与制造业有着千头万绪的分割;而《凤凰我的项目》一书中间接用生产工厂来点化故事的主人公,与IT开发运维间接类比; DevOps施行中,能够借鉴精益实践中的很多思维,例如:升高批量规模、缩小半成品、缩短并加强反馈回路、价值流图剖析、工夫线剖析、打消节约,以及麻利中继续集成、继续测试、继续交付、继续监控、A/B测试、灰度公布、滚动更新等。 十一、三步工作法《凤凰我的项目:一个IT运维的传奇故事》中倡议的三步工作法以实现DevOps: 第一工作法:(帮忙了解在工作从开发移向IT运维时该如何建设疾速工作流)从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化,须要小的批量规模和工作距离,绝不让缺点流向上游工作重心,并且一直为了整体指标(绝对于开发性能完成度、测试发现/修复比率或运维有效性等部分指标)进行优化。必要的做法:看板、继续构建、集成以及部署,按需创立环境,严控半成品,以及构建起可能顺利变更的平安零碎和组织。第二工作法:(如何缩短以及放大反馈环路,从而在源头解决品质问题)价值流各阶段自右向左的疾速继续反馈流,放大其效益以确保防治问题再次发生,或者更快的发现和修复问题。这样咱们就能在所需收入获取或潜入常识,从源头上保证质量。必要的做法:在部署管道中的构建和测试失败时“进行生产线”;日复一日的继续改良日常工作;创立疾速的自动化测试套装软件,以确保代码总是处于可部署的状态;在开发和IT运维之间建设独特的指标和独特解决问题的机制;建设广泛的产品遥测技术,让每个人都晓得,代码和环境是否在依照设定运行,以及是否达到了客户的指标。第三工作法:(如何建设文化,技能激励碳酸,从失败中吸取教训,又能了解重复的工夫是精通工作的先决条件)发明公司文化,带动两种风尚的造成:一直创世,这须要承担风险并从胜利和失败中吸取经验教训;了解反复和练习是熟练掌握的前提。一直加压,从而强化习惯并加以改进。(零碎里要常常出些故障,长此以往,再遇到困难就没原来那么苦楚了)必要的做法:营造一种勇于创新、敢于保险以及高信任度的文化,把至多20%的开发和IT运维周期布局给非功能性需要,并一直激励进行改良。十二、KPI与度量为了促成DevOps策略,调整绩效考核和激励机制是必要的,本来按各自为政的KPI考核只会造成部门之间的隔膜,仍然只依据敲出代码的生产力来处分开发人员,或者依据基础设施的可靠性来处分运维人员,什么都无奈扭转;围绕业务零碎而不是职责来组织工作,这就是DevOps突破IT分组壁垒的寓意。 团队一起合作,独特为他们的利用和零碎负责。 局部度量参考: 开发利用所破费的最高工夫(开发速率)失败部署的百分比(部署成功率)客户产生了多少问题(客户接受度)故障复原的均匀工夫(团队解决故障的能力)用户数(用户欢送度)作者:IDCF社区冬哥 IDCF社区共创读书会 首期汇报,每周四晚8点,冬哥有话说收费直播,关注公众号回复“共读”获取直播地址 8月19日,共读《思考,快与慢》8月26日,共读《DevOps实际指南》9月2日,共读《麻利无敌之DevOps时代》

August 20, 2021 · 1 min · jiezi

关于devops:阿里巴巴-DevOps-工具体系

简介: 随着阿里巴巴多元化业务 20 多年的高速倒退,技术体系经验了 web 时代、挪动化时代、数据智能时代、云计算时代等多个重大改革。在这些改革中,开发者面对的技术体系、工具体系、常识体系也在一直进化。研发工具在其中起到了技术规模化和降本提效的关键作用。 随着阿里巴巴多元化业务 20 多年的高速倒退,技术体系经验了 web 时代、挪动化时代、数据智能时代、云计算时代等多个重大改革。在这些改革中,开发者面对的技术体系、工具体系、常识体系也在一直进化。研发工具在其中起到了技术规模化和降本提效的关键作用。 工具体系总览通常企业中技术人员会依照技术工种分为前端、挪动端、服务端、数据、算法、测试、运维等多个角色,这也代表着以后软件工程畛域的几大技术分工。每种技术栈都有本人独有的技术倒退门路和配套工具集,在阿里巴巴除了这种纵向的技术维度切分以外,还存在依照用户感知门路从前往后的横向切分。比方偏差业务侧的 no-code/low-code 编程,偏差通用侧的 pro-code 编程等。 研发工具体系倒退大体分为:技术栈标准化、工具流程平台一体化、细分场景技术多样化三个次要阶段。 在一种特定技术畛域倒退初期或者公司刚成立之时,会呈现技术框架百家争鸣,多种研发流程并行的状况,通常支流技术栈收敛是晋升研发效率的第一抉择。比方阿里开发中 Java 技术栈人员占比超过 50%,基于 Java 技术栈演进出的中间件、编程框架、配套工具,以及研发流程会高度耦合,造成对立研发解决方案。 解决方案的产品化会诞生一体化的工具流程平台,而此平台对企业的外围收益在于将固有流程标准化和自动化,抬升了所有技术员工的技能底线,从而晋升均匀人效。另一方面工具平台能够帮忙企业积攒可用资产,并将过程数据进行汇总剖析,为管理者提供决策依据。 研发工具倒退的第三阶段是与企业业务深度耦合和定制后的场景化,实现特定畛域的效力冲破。比方 OA 畛域的无代码编程、前端智能化 P2C、服务端函数编程等。 阿里巴巴 DevOps 平台咱们通常所说的 DevOps 是打算、代码、开发、测试、公布、运维、监控的全流程,分为三大阶段:需要分析阶段、代码开发阶段、交付运维阶段,别离对应以需要为核心、以代码为核心、及以利用为核心的三个工具平台。 平台首先须要解决的是如何治理企业研发类资产的问题,通常分为常识类资产(需要、文档、设计图等)、代码类资产(程序、配置、数据等)、利用与资源类资产(实现对外服务的逻辑单元以及背地的物理资产)。其次须要记录研发过程所产生的数据,用于剖析寻找晋升效率的门路。 工具平台会将资产数据和过程数据积淀到对立的数据中台之上。而串联数据的正是 DevOps 从打算到监控的标准化流程。在阿里咱们称之为价值流,代表着一个业务价值从定义到实现的全过程,而这种价值交付的速度正是研发效力。 基于“云”的 DevOps 体系以后企业上云简直成为必选,建设 DevOps 体系的时候必须要思考“用好云”的问题。从阿里巴巴的教训来看,“用好云”的要害是给开发和运维两种角色别离建设用云的工具切面。 运维或者 SRE 这个角色是基础设施的创立和维护者,他所关注的是大量零散的 IT 资产,如何治理这些资产,管制其生产和运维流程是最重要的。咱们会抉择一个基于 ITIL 或者 ITSM 的“云资源管理平台”来帮忙运维人员晋升管理效率,因而称之为面向“资源”的管云界面。 开发和测试所关注的是如何疾速平安的将业务需要转变为线上能够被应用的服务。一个或多个服务的组合咱们称之为“利用”,而利用能够运行在一系列云资源之上,因而它会变成一系列资源的逻辑归组。咱们会建设利用的开发、测试、运维流程,并将这些流程配置到一个“利用治理平台”之上,这就是面向“利用”的用云界面。 在阿里巴巴,咱们通过“云资源管理平台”和“利用治理平台”实现了产研人员与云的无效连贯,并通过平台的流程形象,实现了对云技术细节的屏蔽,晋升了各角色用云的效率,并将企业“资源”与“利用”两种最重要的资产积淀下来。 DevOps 工具的云原生趋势随着 kubernetes、容器化、Serverless、Service Mesh 等齐全基于云的技术体系逐渐成为业界事实标准,云原生化成为了泛滥企业技术升级的指标。DevOps 工具体系须要进行降级以适应云原生的发展趋势。 Kubernetes 是云原生的代表技术,首先它从容器编排能力开始一直演变,岂但实现了对底层物理资源的无效屏蔽,还倒退出十分强的可编程的扩大能力。基于此能力倒退出了一些列中间件、运维工具,甚至是编程框架;其次它具备面向终态的个性,这种申明式的资源运维模式与传统面向过程的运维模式有着本质区别,有机会彻底解脱人的管制,实现无人值守的变更。因而云原生的 DevOps 工具岂但须要适配云原生的技术和产品,而且要可能继承面向终态的思维,来进一步晋升研发运维效率。 阿里巴巴将 GitOps/IaC 理念与云原生技术相结合,并交融传统利用治理教训产生了新一代云原生研发运维平台。相比传统模式,新平台具备以下几个特点。 ...

August 9, 2021 · 1 min · jiezi

关于devops:DevOps-能力提升模型

简介: DevOps 能力反映的是技术研发响应业务变动的能力。随着组织规模的减少和业务复杂性增长,DevOps 能力会变得越来越重要。继续晋升 DevOps 的能力成为技术研发的独特挑战。 编者按:本文源自阿里云云效团队出品的《阿里巴巴DevOps实际指南》,返回:https://developer.aliyun.com/...,下载完整版电子书,理解阿里十年DevOps实践经验。 DevOps 能力反映的是技术研发响应业务变动的能力。随着组织规模的减少和业务复杂性增长,DevOps 能力会变得越来越重要。继续晋升 DevOps 的能力成为技术研发的独特挑战。 为了给组织的 DevOps 能力晋升指明方向,并布局清晰的门路。咱们定义了 DevOps 能力成熟度模型,它提供两个价值:1)晓得咱们明天在哪里;2)如何布局晋升门路。 咱们将 DevOps 的施行,合成为 4 大类,10 个能力,别离是: 根底能力:包含零碎的服务化程度和基础设施程度两块,它是研发和交付的根底。其中,服务化程度跟利用架构严密关联,最现实的状况是无服务化架构,比拟低级的情况是整个零碎耦合在一起的巨石架构;基础设施程度体现为研发对基础设施所须要的关注度,须要的关注度越高,研发花在基础设施上的老本越高,效率越低,而且稳定性反而难以保障。 交付能力:包含工具化程度、测试自动化程度和部署公布程度三大块,它是工程能力程度的次要体现。其中,工具化程度指的是研发全流程中波及到的各类工具的整体程度,包含单点能力(如我的项目合作工具、构建工具、依赖管理工具、环境管理工具等)和协同能力(如需要与公布的零碎、缺点与测试的买通等);测试自动化程度指测试的反馈效率和自动化水平,测试自动化是工程能力的重要组成部分,也是晋升部署公布能力的根底;部署公布程度是指把制品上线到生产环境并提供服务的能力,包含公布的自动化水平、稳定性(如平滑的灰度公布)和适应性(即面向不同状况的解决能力及呈现问题后的自愈能力)。好的交付应该是继续、疾速、高质量和低危险的。 运维能力:包含零碎的可观测性、利用的运维程度和基础设施的运维程度,是零碎运行时弹性和韧性程度的体现。其中,可观测性是运维能力中最重要的一环,次要体现在是否站在零碎的角度看到全局的运行状况以及其中的问题,通常体现在监控程度和链路剖析及问题定位能力上;利用运维是指对利用进行的运维操作,包含配置项的批改、调整利用运行时参数、对利用进行调整如扩缩容等;基础设施运维是指对系统的基础设施局部的运维操作,包含虚拟机、容器平台、根底服务(如域名、配置核心等),这是整个零碎的根底局部。最好的运维就是自运维。 协同能力:包含业务和技术间的协同,以及开发与运维的协同能力,它是整体协同和业务响应能力的体现。其中,开发和运维协同是为了交付过程更加顺畅和高效,以进步技术的响应速度,同时保障系统运行的弹性和韧性;技术和业务协同是为了让从业务到技术的价值传递和交付更加精准、高效,反馈更加即时,以进步业务倒退和翻新的效率和成果。 成熟度模型基于这 4 大类 10 个能力,咱们给出了一个蕴含 5 个级别的成熟度模型,从 L0 到 L4 成熟度顺次递增。 L0:手工批量交付、手工运维,这是零能力的 DevOps 阶段,其服务能力齐全取决于开发者集体,业务交付品质广泛不高,随着业务的倒退和团队规模的变大会遇到各类问题,通常会首先寻求工具的帮忙。 L1:手工为主、工具辅助的批量交付和运维,这个阶段开始引入自动化工具来辅助进行运维、公布等工作,通常曾经有了服务化的根底,基础设施曾经局部上云,并通过引入开源工具或自建搭建了一些实现特定诉求的工具,但这些工具往往还是孤岛,没有分割起来,业务、开发、运维间采纳定期同步的形式,需要的交付还是批量式的。 L2:基于业务需要的局部自动化的交付运维,这个阶段能基于业务需要进行继续公布,曾经采纳了申明式运维,通常曾经应用云原生的基础设施,并且应用云上的资源管理服务状态,大部分工具链曾经能串联起来,实现肯定水平的继续交付,服务开始具备中间件级别的形象和治理能力,但个别还无奈做到自运维,回滚等操作还须要依赖人来判断和解决。 L3:基于业务需要的端到端自动化交付和有限度的自运维,这个阶段的业务需要交付频率和交付品质有了明显提高,服务化程度曾经相当高,针对特定的技术栈能够做到大部分状况下关注业务开发,次要服务以serverless 形式公布运行。公布过程能够做到自动化和申明式,只在灰度解决上须要大量的干涉,服务曾经能够做到大部分状况下的自运维和自治理。 L4:业务需要的端到端继续交付和调整闭环、齐全自运维,这个阶段开发者只需关注业务开发,且业务需要可能做到疾速的交付和调整,服务化程度与技术栈解耦,做到齐全 serverless 化。整个交付过程齐全自动化,服务可能齐全自治理。这个阶段是咱们谋求的指标。 原文链接 本文为阿里云原创内容,未经容许不得转载。

August 2, 2021 · 1 min · jiezi

关于devops:2021年中国DevOps现状调查报告发布

摘要:为进一步理解和把握DevOps在中国落地实际的现状和将来发展趋势,中国信息通信研究院依靠云计算开源产业联盟,此次联结华为云DevCloud等40余家企业独特发动“2021年中国DevOps现状考察”。本文分享自华为云社区《信通院携手华为云DevCloud等多家单位公布中国DevOps现状调查报告(2021年)》,作者:灰灰哒 。 近日,由中国信息通信研究院举办的“2021中国互联网大会-数字化治理论坛”在北京国家会议核心胜利召开。会上,中国信通院云计算与大数据研究所治理与审计部重磅公布并解读了《中国DevOps现状调查报告(2021年)》。 为进一步理解和把握DevOps在中国落地实际的现状和将来发展趋势,中国信息通信研究院依靠云计算开源产业联盟,此次联结华为云DevCloud等40余家企业独特发动“2021年中国DevOps现状考察”。 参加本次考察的企业包含互联网、科技、电信、金融、制作、教育、征询与服务和批发等行业,聚焦中国DevOps实际成熟度现状,对DevOps转型现状、将来DevOps的倒退、企业对政策/资质的需要等状况进行了考察,共回收无效问卷1862份。 (版权申明:本报告版权属于云计算开源产业联盟,并受法律爱护。转载、摘编或利用其它形式应用本报告文字或者观点的,应注明“起源:云计算开源产业联盟”。违反上述声明者,本院将追究其相干法律责任。) 麻利已成为支流研发模式考察结果显示,麻利已成为软件开发的支流研发模式,超过半数企业学习或实际过Scrum或Kanban;85.16%的企业抉择了继续集成。但仅有三成企业具备对立的工作项管理系统,可视化变更生命周期和全程数据分析能力有待晋升,次要体现变更治理。 华为云DevCloud针对麻利的需要,提供端到端的DevOps施行框架,是联合了华为30年研发教训并汇合了业界先进的实际所造成的一套可操作可落地的麻利开发方法论,在一站式全流程的华为云DevCloud软件开发平台上进行承载并提供给企业及开发者应用。 更器重平安平安方面,企业关注代码安全性、平安测试与破绽扫描、第三方开源库的安全性、设计合乎平安规范和标准等平安问题,内部威逼与攻打及个人信息爱护也受到企业器重。考察结果显示,近五成的企业有业余平安团队,较去年增长一成;五成以上的企业尝试实际DevSecOps;企业自动化平安测试继续向全流程笼罩演进,可帮忙企业尽早发现问题防止平安危险。 基于平安与DevSecOps的强烈诉求,华为云正在逐渐的将华为20年来深耕平安的能力通过云服务的模式外溢,让更多的企业能共享华为对于平安的先进理念和技术实际,华为云DevCloud通过让在DevOps的每个环节都通过标准、方法论和自动化的平安服务,来实现DevSecOps的理念,如在创立利用阶段平安框架和编码标准,嵌入IDE插件的代码查看等。 DevOps转型现状本次报告还提到了DevOps转型现状,其中研发效率的晋升、产品质量、按时交付和客户满意度是企业判断DevOps转型胜利与否的4个次要根据。很多企业通过引入培训、公司高层推动等多种形式赋能DevOps转型,但在转型过程中,仍然会遇到很多问题,次要问题有3个: 1. 我的项目团队工作沉重,没有工夫进行DevOps 改良 考察结果显示,29.48%的企业我的项目团队工作沉重,没有工夫进行DevOps改良,同比增长4.02%。 2. 不足相干领域专家 29.05%的企业短少具备DevOps 教训的专家,导致推动迟缓无从下手,同比持平。 3. 未造成跨组织畛域及自我驱动改良的度量体系 考察结果显示,15.82%的企业在整个开发生命周期的各个阶段均定义了度量指标,但度量指标仅限于部门外部;14.50%的企业建设跨组织度量指标,进行跨畛域综合维度的度量。仅有21.89%的企业没有定义度量指标。 企业对研发经营一体化(DevOps)能力成熟度评估的关注水平继续上涨。考察显示,63.64%的受访者对DevOps 能力成熟度评估感兴趣,相比2020年增长近一成。 华为云DevCloud专家服务目前提供了DevOps成熟度评估, 能够实时获取报告,能够点击上面链接进行体验。 点击体验华为云DevCloud 体验DevOps成熟度评估 点击关注,第一工夫理解华为云陈腐技术~

July 31, 2021 · 1 min · jiezi

关于devops:从Helm2迁移到-Helm-v3-的最佳实践

在 JFrog,咱们依附 Kubernetes 和 Helm 来编排咱们的零碎并放弃咱们的工作负载运行并放弃最新状态。 咱们的 JFrog Cloud 服务最后应用 Helm v2 和 Tillerless 插件部署以加强安全性,但当初咱们已胜利将数千个版本迁徙到 Helm v3。 与许多 SaaS 服务提供商一样,JFrog Cloud 在不同地区的许多 Kubernetes 集群中运行,包含 AWS、Azure 和 Google 云提供商。 咱们在此过程中学到了一些重要的经验教训,很快乐与大家分享。 为什么迁徙到 Helm v3Helm v3 的第一个版本于 2019 年 11 月公布, Helm v2 在一年内依然有更新版本。 然而随着 Helm 2.17.0 的最终版本于 2020 年 11 月公布,Helm v3 当初曾经是 Helm 开发者社区反对的唯一标准。 Helm v3 提供了一些重大改良,最显着的是删除了 Tiller。 这个集群内的服务器与 Helm v2 客户端交互的须要管理员权限能力执行其职责,这被认为是共享 K8S 集群中的平安危险。 这能够通过 Tillerless 插件来克服,但 Helm v3 不再须要这样做。 ...

July 21, 2021 · 2 min · jiezi

关于devops:阿里巴巴DevOps实践指南-全景监控

开发者工具打造围绕开发者全生命周期的工具产品https://developer.aliyun.com/...;utm_content=g_1000283729 随着云原生技术的倒退与演进,微服务和容器化技术成为大型分布式 IT 架构的必然选择。新技术在让 IT 零碎变得更麻利、强壮、高性能的同时,也带来了更高的技术架构复杂度,给利用监控带来了前所未有的挑战。 传统监控挑战系统监控爆炸式增长传统监控重点关注利用、主机、网络等零碎层面的监控。随着微服务、云原生等新技术的大量使用,零碎架构越来越简单,利用数量呈爆炸式增长。当一个故障产生时,大量零碎报警会产生报警风暴,使得技术人员无奈疾速定位问题。同时,大量的零碎级监控会产生大量误报,技术人员被迫破费大量的精力去解决这些误报,最终对报警产生麻痹。 监控后果和业务指标之间欠缺分割传统监控短少业务视角的监控,以及业务与 IT 零碎之间的分割。这导致用户、业务人员和技术人员之间无奈造成对立视角。很多故障往往是用户曾经反馈,技术人员却在用系统监控指标证实零碎没有问题。或者业务曾经受损,技术人员仍然无奈确定是哪个零碎的问题,复原工夫被大大拉长。 监控工具之间数据割裂,数据不足剖析以往阿里巴巴采纳多种监控工具,用于监控网络、物理机、利用、客户端等不同的对象,但不同工具之间无奈共享数据,监控数据不足对立的剖析,更加难以跟业务场景相结合,造成大量的故障只能依附技术人员的教训,在多个工具之间一直地切换和逐渐排查,大大增加了故障复原时长。 监控保护老本高,报警准确率低传统监控都须要大量的配置工作,整个过程麻烦费劲,不足自动化、智能化监控的伎俩,这也是造成各系统监控能力参差不齐的重要起因。一些新业务因为有力投入大量精力配置监控,导致业务监控能力缺失。同时,随着业务的倒退,技术人员须要一直地调整报警规定,又经常因不及时的调整造成误报和漏报。 业务驱动的监控理念为了适应 DevOps 研发模式,解决传统监控的问题,阿里巴巴总结了一套以业务驱动的自顶向下的全景监控体系,次要包含:业务监控、利用监控和云资源监控三层: 业务监控是整个监控体系的“顶层”,可能反映用户应用业务的真实情况,能够与业务后果间接挂钩,可能被不同部门、不同角色的人员所了解。利用监控提供利用中服务和零碎层监控能力,可能间接反馈零碎运行状态,帮忙研发人员全面理解利用中服务和中间件的衰弱状态,疾速定位系统问题。云资源监控提供利用依赖的各类云资源(如 RDS、OSS、SLB 等)的根本监控,在故障排查中可能为研发人员提供实例级别的明细监控数据,疾速确定是利用零碎的问题,还是云根底施行的问题。监控分层当前,各层的监控指标和报警规定会按重要水平分成重大、正告、一般等多个等级,不同档次、不同级别的监控报警会被分派给不同的角色来解决,比方团体的平安生产团队只关注全团体的外围业务指标,事业部的稳定性负责人关注部门级的外围业务监控,每个团队的研发人员则接管本人负责业务和利用报警,而云资源实例的监控个别不发送告警音讯,次要用于故障排查和定位。这样充分发挥了 DevOps 的劣势,传统模式中多数运维人员成为故障排查瓶颈的问题也得以解决。同时,每个人须要解决的报警数量大幅缩小,也解决了在故障产生时因为报警风暴,而将重要的业务监控报警吞没的问题。 对立的监控架构基于全景监控的理念,阿里巴巴摸索出了一套对立监控的架构,该架构不谋求大一统的监控平台模式,而是采纳分层建设,形象出了云资源,利用,业务这 3 种监控零碎,每种监控都专一发现相干畛域的故障发现,再通过对立 CMDB 解决监控元数据互相不对立的问题,通过智能算法平台,报警核心和故障平台集中管理事件,故障以及晋升准确率。 业务监控阿里巴巴“业务监控”采纳专为监控自研的日志采集&计算框架,通过页面配置即可实时提取日志中的监控指标,具备简略易用、自定义能力强、响应速度快、对业务无侵入等特点;提供了残缺的业务监控畛域模型,疏导用户实现监控笼罩。 业务监控的畛域模型包含: 业务域:一个残缺的业务或产品称为“业务域”,如电商的“交易域”、“营销域”、“领取域”等。业务场景:业务域中的外围业务用例叫做“业务场景”,如交易域的“下单确认”、“创立订单”等,业务场景是整个监控模型的外围。业务指标:体现每个业务场景的特有指标,如每分钟的订单数量、交易成功率、错误码等。在业务指标的抉择上,传统的运维人员喜爱应用穷举式的伎俩配上所有可观测性的指标,各种告警加上,显得有“安全感”。理论当故障来长期,满屏呈现指标异样、一直减少的告警短信,这样的监控看上去功能强大,实际效果却事与愿违。 通过对阿里巴巴历年故障的认真梳理,阿里巴巴团体内的外围业务的常见故障(非业务本身逻辑问题)都能够通过流量、时延、谬误等 3 类指标反馈进去,咱们称之为黄金指标: 流量 :业务流量跌零 OR 不失常大幅度上涨上涨,中间件流量如音讯提供的服务跌零等,都可能触发重大故障;延时 :零碎提供的服务 OR 零碎依赖的服务,时延忽然大幅度飙高,根本都是零碎有问题的先兆;谬误 :服务返回谬误的总数量,零碎提供服务 OR 依赖服务的成功率。业务监控平台提供了“黄金指标”插件,通过单次配置就能够生成一组黄金指标,是目前业务监控应用范畴最广的指标模型。业务监控报警间接与故障关联,对监控数据的品质有很高的要求,同时须要具备很好的灵活性(既满足不同技术实现的监控需要,又不能对被监控的业务零碎造成性能影响)。阿里巴巴的“业务监控”通过日志作为数据起源,能最大水平地保障业务监控的灵活性,可能适应简直所有的技术栈。日志采集采纳了无压缩增量采集、zero-copy 等技术,升高监控采集对业务零碎的性能影响;采纳拉模式架构、重试机制、数据齐全度模型保障了数据采集的可靠性和完整性;齐全白屏化的配置能力、欠缺的调试性能,最大水平升高了用户的配置难度和配置老本。 利用监控阿里巴巴利用监控采纳标准化和组件化的形式搭建,与阿里巴巴技术栈相结合,提供罕用的零碎和中间件层面的监控组件;运维同学无需批改程序代码,整个监控过程自动化,利用上线、扩容后主动开启利用监控,无需人为操作,大幅升高了监控的保护老本。 当运维零碎执行利用上线、扩容等操作后会将变更信息写入到 CMDB,CMDB 会将变更信息推送到MQ,利用监控平台订阅 MQ 实时获取利用的配置变动生成新的监控工作,监控工作下发到指定的指标服务器(容器)的 Agent 端,Agent 依据工作的配置信息发送对应的采集申请,从业务利用提供的 Exporter 等 EndPoint 中获取监控数据,并上传到监控集群进行计算和存储;同时异样检测模块也会依据利用配置的变动生成报警检测工作,从时序数据库中拉取监控数据进行异样检测,并将异样事件发送给报警核心。 云资源监控阿里巴巴云资源监控间接对接阿里云平台的“云监控” API 获取各类云资源的指标数据和报警事件,再将这些数据与 CMDB 中利用与云资源的关系信息连贯,最终造成利用视角的云资源衰弱状态视图,解决了云基础设施监控与下层利用监控互相隔离的问题。依靠云平台的监控能力和 CMDB 的数据积攒,整个云资源监控也是自动化实现的,无需用户人工配置。 智能检测平台为了解决报警准确率低、配置保护老本高的问题,阿里巴巴建设了智能检测平台,通过 AI 算法准确地发现线上业务和利用的异样,并且在此过程中不须要任何人工配置报警阈值。针对业务和利用监控数据的不同特点,采取不同的异样检测策略: 1、 智能基线 ...

July 21, 2021 · 1 min · jiezi

关于devops:阿里巴巴DevOps实践指南-云端开发

开发者工具打造围绕开发者全生命周期的工具产品 https://developer.aliyun.com/... 云端开发指开发者可基于云平台实现编码、测试、公布等研发流程。一个残缺的云端开发平台不仅是提供了一个云端的编码环境,还提供了一整套研发工具和配套设施,让开发者做到在云端即可实现应用程序的需要、编码、测试和运维的全生命周期治理。 传统的本地开发的问题如下图所示,在传统的开发模式中,企业研发人员通常在本地实现代码的编写和测试,而后把代码推送到远端服务器,通过一系列的构建和集成,最终公布到生产环境,并继续利用线上的运维体系实现线上零碎的监控和运维;同时,企业也会采集局部研发过程中的要害数据,用来度量团队及集体的效力。 随着各种软硬件技术逐步更替,公司规模也越来越大,为了适应这种变动: 公司须要一直为企业研发人员配备适合的本地研发工具(如:多核高内存的计算机设备、Mac 笔记本电脑),这些设施可能价值不菲,而且须要定期的更新换代;新退出的员工,在正式开始开发前,须要配置简单的本地开发环境,装置特定的软件及插件,并相熟我的项目的研发流程及各个线上零碎; 局部我的项目因为网络配置等问题,可能第一工夫还无奈在本地启动,还会耽搁不少额定的配置及调试工夫;公司须要投入较多的资源,能力构建起匹配管理者需要的效力度量零碎和平安管控零碎,并且因为云端体系天生对开发者本地环境的弱管控性,成果只能差强人意;阿里巴巴也不例外,随着近些年各项业务的飞速发展,人员的疾速裁减,如何解决倒退过程中带来的相似问题变得火烧眉毛。而云端研发作为一种新兴的技术模式,其独特的劣势恰好能够用来解决上述问题。云端开发的典型利用案例案例 1:前端组件的开发在阿里外部,存在大量的基于 Node.js 构建的前端工程,这些前端工程广泛采纳模块化的组织形式,在开发过程中会随着需要迭代产生泛滥的模块(或组件)。同时,有些前端工程会邀请业务方参加共建,即由提出性能需要的团队在大的规范下自行开发组件,并公布上线,在平台中集成本人的场景。 在这样的背景下,组件的开发会被高度的形象,大部分的步骤都能够由工具辅助实现(如下图中,业务开发人员只须要关注本人的业务逻辑即可),这样既晋升了研发效率,又晋升了组件的开发品质。 前端组件开发过程: 云端开发的开箱即用,恰好能够解决相似的问题。开发者关上浏览器就是一个配置好的环境,实现零配置上手;而环境配置能够由项目组的资深共事保护,配置好针对某个我的项目的零碎版本、程序运行时、SDK 和 IDE 插件汇合。相比应用本地的研发工具,云端开发能够实现: 研发流程的产品化,从组件的新建到最终的公布零打碎敲,不必再在多个平台工具上来回跳转;屏蔽用户操作系统的差别,提供对立的研发环境,不必再解决 Windows/Mac 的差别,不必放心本地Node.js 的版本问题;所有环境都会预装好必要的开发提效工具,如:规约扫描和修复工具、预览调试工具、各环境公布工具等;充沛开释本地磁盘空间,不必放心磁盘被 node_modules 占满; 案例 2. 代码平安管控与研发过程数字化度量在政务、金融以及局部高科技企业的研发场景中,对代码的平安管控要求极其严格。但近几年,公司外部源代码泄露的事件时有发生,有的被明码标价进行发售,标价数十万甚至上百万美元;有的间接被公开在网络上,任何人都能够拜访下载。一旦产生相似事件,将会间接或间接造成商业信息泄露及公司名誉受损。 当应用本地开发时,源码的传输环境、本地的长久化介质不可控,对于员工无意泄露源码的行为仿佛无可奈何。当应用云端开发时,所有都迎刃而解:开发者能够从代码库或需要间接关上网页开始云端开发,研发过程中代码不落本地磁盘,既能缩小传输危险,又防止了员工本地环境被植入木马、从而在不知情的状况下泄露源码的可能;同时,在云端开发环境中能够对用户的浏览、拷贝行为做不同水平的管控,联合告警和零碎主动拦挡,可无效升高源码泄露的危险。 在阿里外部,当波及到对保密性要求极高的我的项目,或者当企业内部成员参加对代码保密性有要求的我的项目时,咱们会举荐我的项目团队应用云端进行研发,从而无效避免源码的泄露。 此外,随着越来越多的企业进入到数字化转型阶段,管理者冀望能更加全面的看到企业员工的投入与产出,并且针对我的项目人员散布与研发过程效率做出更加及时的调整与改良。在过来,所有的数字化信息都依赖人工的反馈和统计,反馈的是否精确、统计过程中是否有纰漏都会间接影响管理层的判断。但如果把研发过程搬到云上,所有的研发过程数据就能生在云上、用在云上,想要借助数字化晋升研发效率变得更加容易。 在阿里外部,团队中常常会呈现一名正式员工率领多名企业内部成员实现我的项目的状况。在须要对企业内部成员的工作进行绩效评定时,传统的评定形式通常是参考需要实现数量、代码缺陷率等指标,但理论工作中需要有大有小、有难有易,齐全基于后果指标进行评定很难做到偏心公正,让优良的员工怀才不遇。借助云端开发,能够让所有研发过程中的数据也通明进去,如各需要的编码时长、长期版本公布次数、过程代码与最终无效代码的比例、单位工夫代码产出量等。通过联合研发过程数据,也能够让绩效评定更加通明公正。 总结云端开发具备灵便定制、开箱即用的特点,借助好这两个个性,就能够创新性的解决掉传统本地开发过程中的顽疾。除了上述两个案例外,咱们认为,以后适宜云端开发落地的场景还能够是: 1、云原生场景中的轻量代码开发,如 Serverless 场景,这类场景中研发人员只须要集中式的编写业务逻辑,大量的框架类代码已被默认暗藏,并且调试、部署形式有别于传统研发过程,更适宜云端开发的落地。2、各类垂直化的场景,这类场景通常须要有针对性的定制,与特定的线上零碎进行买通,只有能利用好云端开发灵便定制的个性,就无望实现开发阶段 10 倍效力的晋升。

July 20, 2021 · 1 min · jiezi

关于devops:甩掉包袱在竞争中自我迭代-IDCF云智慧DevOps黑客马拉松挑战赛第四期精彩回顾

7月10-11日,由云智慧主办,IDCF&英捷创软协办的“云智慧·DevOps黑客马拉松挑战赛(第四期)”在云智慧郑州研发核心举办,云智慧郑州研发核心总经理Neeke缺席较量并进行收场演讲,智能电力事业部-研发部开发经理Fabby Feng为较量致闭幕词,DevOps畛域顶级大咖徐磊、助理教练魏振龙等专家负责挑战赛的领导教练。 本期挑战赛由来自云智慧多个团队的精英组成6支战队,参赛学员全副为90后工程师。这是一支头角峥嵘的队伍,90后新锐工程师们暮气沉沉,现场频频掌声雷动,笑声飞腾。 云智慧团体成立于2009年,是国内当先的全栈智能业务运维解决方案服务商。秉承Make Digital Online的使命,致力于通过先进的产品技术,为企业数字化转型和晋升IT经营效率继续赋能。 云智慧专一于运维畛域的开辟和深耕,是智能运维国家标准制订单位之一。通过多年自主研发,已领有80多项专利技术,造成了从ITOM到ITSM的智能运维产品系列,为金融、政府、运营商、能源、交通、制作等数十个行业客户提供了数字化运维体系建设及全生命周期运维治理解决方案。 云智慧特地器重研发团队的技能造就和以客户为核心的研发效力晋升,通过研发效力驱动客户胜利,第四期IDCF·云智慧DevOps黑客马拉松挑战赛旨在通过培训进一步晋升团队合作效率。 云智慧郑州研发核心总经理Neeke在收场演讲中提到:在2天1晚的马拉松实战培训中,心愿大家可能甩掉日常工作中的包袱,与长期小组成员一起,突破边界、跳出束缚,还原最本真的守业状态,实现切切实实的效率晋升、组织晋升、集体能力晋升。 DevOps黑客马拉松挑战赛简介DevOps黑客马拉松是由IDCF独创的、学练赛一体的金牌训练营,模仿实在业务场景,体验端到端DevOps,在36个小时内经验7个模块,使用迷信的DevOps办法,从商业模式布局开始到我的项目路演完结,残缺经验一次商业翻新过程,现场公布一款翻新产品。较量过程中,将精益守业+麻利开发+DevOps流水线完满联合,至今已有数千人参加并统一五星举荐。 本次DevOps黑客马拉松日程 模块0:前序常识导入。学习端到端DevOps 5P框架,根本认知DevOps理念及办法;模块1:产品翻新。练习如何为你的产品设计一个鼓舞人心的愿景;模块2 :产品性能布局。通过用户画像摸索标签及痛点,利用用户故事地图梳理产品外围性能,梳理产品愿景、定义产品外围价值,构建产品MVP原型;模块3 :迭代打算。学习把握迭代指标设计、工作拆解与认领等技巧,设立物理看板并筹备执行;模块4 :打造继续交付流水线。搭建开发环境与分支策略,搭建继续交付流水线,梳理微服务架构并实现第一个迭代MVP版本的线上交付;模块5:终极PK。下台公布产品,展现阶段性产出,评委打分;模块6:闭营。颁奖、获奖感言。IDCF·云智慧DevOps黑客马拉松挑战赛(第四期)将挑战者分为6个战队,较量重视战队成员间的合作,经验了团队搭建-达成共识-构建愿景-开始合作-梳理打算-绘制蓝图等多个步骤,各战队造成对立指标,在实践中充分发挥各角色能力,最终所有战队都挑战胜利。 精彩回顾1、团队搭建之初,各小组就以黑马挑战赛冠军为指标,并将指标写在团队公约上。高度集中的指标和竞争态势,让整场较量充斥着浓烈的火药味,在比赛气氛中疾速排汇常识,疾速实际,疾速迭代,疾速产出。 2、整场较量氛围低落,既有总结分享环节2个小组一个抢话筒,一个占讲台,势必要争出一个高下;又有灵魂舞者,拍拍操互动中凭借一己之力嗨爆全场。 3、流水线搭建环节,各组体现出极客精力,三支队伍并列第二,全力拿下每一个加分项。流水线现场演示,10分钟,从0到1搭建一条流水线;大家一起来抓虫,学员踊跃下台修Bug;5分钟,从发现问题到修复上线,生动有趣且直观学习到成熟流水线的威力。 4、“只有想干,环境不是问题!”凌晨1点的公司工位、汽车后座均为撸码战场,各组在抢夺冠军的比拼中,既体现了研发实力,又体现出对整体竞争态势、竞赛心理的洞察。较量中,各组纷纷使出“瞒天过海”之计,全程暗藏得分直至最初阶段才亮出底牌。 5、本期黑马在培训模式上也有诸多翻新降级:迭代打算模板化;可视化看板模板化;引入电子版布局卡片PlanningCard;间断三个启发式互动环节带出用户故事地图,让学员粗浅体验需要形容、拆解和布局的原理。 6、本期黑马正式公布DevOps黑客马拉松学员手册彩印版。 7、乏味的是,本期较量合影时的河南话版“云智慧·黑马·挑战胜利~”,堪称极具当地特色。 奖项揭晓IDCF·云智慧DevOps黑客马拉松挑战赛设置了最佳黑马团队、最佳流水线、最佳创意、最佳黑马精力、最佳演讲集体等多个奖项,通过36个小时的实际与比拼,六支参赛队伍全副实现挑战,并展现了十分优良的路演作品。 通过强烈的角逐和评委评审,各奖项得主也最终揭晓。 最佳黑马团队:第二组 “多鱼科技”战队第二组在较量开始时就以冠军为指标,在强烈的竞争中,将压力转化为鞭策团队提高的力量,让团队更加高效地实现我的项目,最终拿到冠军团队奖。 冠军组在获奖感言中提到:“最后就定下了以冠军为指标,有了这个指标,咱们更加聚焦,在拼尽全力后,能力更多感触到胜利的成就。” 最佳流水线奖:第五组“黑五科技”战队在流水线搭建环节,比拼一度非常缓和、强烈、刺激,各组施展本身技术上的劣势能力,全面翻新提效,三支战队并列第二,而第五组以最先买通流水线的效率劣势夺得流水线大奖。 最佳创意奖:第四组“轻易开个公司就是玩”战队第四组在我的项目设计上提出别树一帜的我的项目设计,感动评委,拿下最佳创意奖。 最佳黑马精力奖:第二组“多鱼科技”第二组以冠军为导向,全程斗志昂扬,始终不摈弃不放弃,团队成员之间密切合作互帮互助,深刻开掘商业机会与用户需要,最终博得最佳黑马精力荣誉大奖。 最佳演讲集体:第一组“云景股份”战队来自智能电力事业部的Ray Wei路演PK环节,各组都体现出对我的项目的谨严思考,对商业的敏锐洞察,对用户的深刻了解,对技术的精益求精,最终第一组“云景股份”战队来自智能电力事业部的Ray Wei荣获最佳演讲个人奖。 除以上各获奖团队外,第三组“极客近海”战队、第六组“2D1N-两天一夜”战队都挑战胜利! 残缺的DevOps办法,驱动研发效力晋升赛后采访,很多学员示意:在此次培训中,对故事地图、麻利看板、DevOps、看板等麻利和DevOps的办法和工具记忆粗浅,真正了解了残缺的DevOps办法。 学员代表来自智能电力事业部-研发部的开发工程师Luke在赛后发言中说到:“工夫尽管很短,但大家都利用所有工夫将我的项目最终实现;较量现场火药味很浓,激发了每个人的好胜心,在竞争中推动团队指标高效达成;通过学习,对麻利和DevOps有了清晰的方法论,而不仅是停留在概念上,对后续在工作中优化有很大帮忙。” 在较量过程中,很多学员更加粗浅地感触到了团队的力量,一群人一起想到一个创意并为使之实现而致力,在获得技术上的提高时感触到喜悦。在较量中,有同学为调通nGrinder而开心,为意识开源Pipeline、接触了云原生而冲动,为学习了Jenkins流水线利用而骄傲,为把握看板进行多任务可视化项目管理而自豪。 技术的提高在点滴中积攒,最终实现冲破,残缺的DevOps方法论帮团队达成共识,高低同频,彼此造成合力。 智能电力事业部-研发部开发经理Fabby Feng在赛后总结中说到:云智慧多期DevOps黑客马拉松挑战赛中,这一期火药味最浓,较量中有竞争有单干,团队间互相帮助,协力实现挑战。通过多期黑马挑战,参赛者在流水线等各方面体现越来越完满,同时较量自身也在不停地迭代与降级,这都与麻利自身的理念相符合,而在自我迭代的过程中,在较量与工作的过程中,不要给本人设限,放下包袱,跳出解放,能力实现更大冲破。 DevOps黑客马拉松截止到目前已举办了十余期,在较量中,既能够学习到残缺的DevOps和麻利常识体系,又能够帮忙团队在思维意识和技术方向上达到对立,更能够帮忙团队管理者跳出工作禁锢,找到团队麻利、效力晋升的破局点。 IDCF DevOps黑客马拉松,独创端到端DevOps体验,精益守业+麻利开发+DevOps流水线的完满联合,2021年仅有的3场公开课,数千人参加并统一五星举荐的金牌训练营,谋求卓越的你肯定不能错过!关注公众号回复“黑马”即可报名 北京:7月30-31日上海:9月11-12日深圳:11月20-21日

July 16, 2021 · 1 min · jiezi

关于devops:阿里巴巴DevOps实践指南-以特性为核心的持续交付

开发者工具打造围绕开发者全生命周期的工具产品https://developer.aliyun.com/... 随着微服务架构和云原生技术的成熟,继续交付的理念也深入人心。继续交付要求开发团队继续、高频地向生产零碎交付软件。然而,一直增多的服务数量,给企业交付流程治理带来了微小挑战。同时,在 DevOps落地的过程中,逐渐凋谢生产环境的公布权限给到开发人员,这种松管控与企业平安生产存在抵触,多利用版本之间的协同问题也逐步凸显。如何解决企业在新技术转型和 DevOps 落地中的痛点,拿到技术改革带来的效力红利,是每个企业包含阿里巴巴都必须面对和解决的难题。 软件交付挑战阿里巴巴 2008 年对淘宝巨型服务进行拆分当前,逐步形成了一套实用于服务化、分布式架构的中间件体系,解决了简单零碎性能和稳定性在业务高速扩张中的瓶颈问题。随之而来的是利用变多、架构依赖简单、人员数量高速收缩、技能参差不齐等等问题。总结下来有以下几个方面: 利用数量多微服务架构被广泛应用当前,首先面临的就是利用数量的疾速收缩。原有研发流程也必须从批量公布模式向继续交付模式转型,否则会导致公布软件的危险和回滚的复杂度不可控。另一方面,测试和运维的工作量因为利用的收缩而倍增,变成整个研发团队的效率瓶颈。突破这种瓶颈的办法就是 DevOps 的全面落地,把整个软件交付过程交给开发来主导,从而解除瓶颈晋升效率。 架构依赖简单微服务架构让利用内依赖变为了利用间依赖,变更过程无奈做到原子化,因而须要很好的模块拆分和接口设计。一方面缩小单个性笼罩的利用数量,变更程序可控、回滚危险可控;另一方面单元测试能笼罩的场景须要集成测试来笼罩,导致开发过程对测试环境的应用频度和依赖度变高,须要稳固、牢靠的环境来保障所有开发人员都能够并行工作。 测试资源老本大测试环境受到资源老本和运维老本双重制约。在业务倒退初期,能够采纳全链路残缺部署加上多套环境的形式来满足研发团队的要求。然而随着业务的疾速倒退和研发团队的疾速扩张,一直地减少环境在老本上曾经无奈累赘。因而须要一套运维高度自动化,高度弹性随用随取,并且能够实现部分隔离的测试环境计划来满足多版本部署需要。 研发协同难研发环节的协同分为开发间协同和测试,开发、运维多角色间协同两种。前者次要解决并行开发、按需上线的问题。后者解决的是在一个交付流程中各司其职、相互束缚,确保软件能高质量、平安交付的问题。在DevOps 场景下软件交付过程由开发人员主导,而测试和运维角色则须要承当流程守护、门禁卡点、提供自动化工具的责任。为了晋升协同的效率,须要一个可能满足以上要求的工具平台来将团队的约定固化下来,确保团队各个角色能够高效率的实现工作。 线上危险大线上的危险来自于两方面,一方面越来越高频的线上迭代意味着出错的概率也在变大,另一方面随着零碎规模变大,传统人防人治的伎俩已不可能满足风控要求。因而必须从出错可能性和出错影响面两个方面系统性地去解决问题,前者关注是否在出错之前对危险进行拦挡,而后者关注零碎变更影响的用户数量和频度。这两种被动和被动进攻措施的相结合,能够无效的解决危险管制的投入产出比问题,从而达到一个比拟优的状态。 解决思路为了解决以上在企业规模增长和新技术利用中的种种交付痛点,阿里巴巴一直摸索和尝试,逐渐摸索出一种适宜这种业务倒退快、软件迭代快、架构依赖简单场景的交付办法和实际,咱们称之为“以个性为外围的继续交付”。它有三个特点: 以个性为外围个性是一个用户能体验到的产品能力的最小单元,其代码可能波及到多个利用,因而个性也是协同多个开发团队实现一个能力的最小单元。以个性为外围的交付过程治理能够无效地将开发、测试等角色连接起来并对立推动,比方组织隔离测试环境、运行自动化测试、编写测试用例、做好测试验收等等。 以利用为载体利用能够间接对应一个服务,是提供一种业务能力的最小单元,也是软件交付和运维的最小单元。能够通过利用串联代码、流水线、环境、测试和资源,以及外围工具链比方监控、数据库、运维、中间件等。开发人员能够在工具平台上定义他的利用,及利用的交付运维过程,比方配置流水线、布局环境、创立资源、设置部署策略等。以独立利用为载体的交付流程能够实现软件交付的原子化,并强制开发升高利用间的耦合性,同时防止零碎级集中式交付模式的惯性。 松管控与强卡点在软件高速迭代下须要兼顾品质和效率,DevOps 模式须要给开发人员足够的自由度来实现软件的线上变更,阿里巴巴联合本身业务特点,在实践上采纳了松管控和强卡点联合的形式。“松管控”体现在有多种流水线能够供开发抉择,利用负责人能够残缺定义这个利用的各种规定,比方如何部署、如何测试、资源环境如何配置。在技术可控的前提下,还能够凋谢线上测试,比方全链路压测和全链路灰度。轻公布,重复原,在每一个利用维度,开发能够随时应用流水线来交付代码,不主张过多的人为限度,重点须要思考的是如果出问题,如何管制影响面,如何疾速复原。“强卡点”是一种软件品质底线思维的体现,比方代码审核和品质红线,规约查看,公布窗口,安全检查,线上灰度卡点等。这些卡点是为了保障团体所有开发工程师步调对立,交付合格的产品。 继续交付的外围是疾速高质量地交付价值,给与开发人员最大自由度,负责开发和运维全副过程。在监控、故障防控工具、性能开关的配合下,能够在保障用户体验和疾速交付价值之间找到平衡点。 总结明天,基于云的开发已成为支流,这是效力晋升的微小机会,同时又对工程实际提出了前所未有的要求。比方,云原生基础设施、云原生中间件和新一代的云软件编程办法等等,都要求有与之适配的实际和工具。在适配新的技术发展趋势过程中,阿里造成了以个性为外围的继续交付工程实际,并且将其内建到 DevOps 工具体系中,以保障实际精确、无效地落地。 编者按:本文源自阿里云云效团队出品的《阿里巴巴DevOps实际指南》,可返回:https://developer.aliyun.com/...,下载完整版电子书,理解阿里十年DevOps实践经验。

July 15, 2021 · 1 min · jiezi

关于devops:DevOps发布策略简介

简介: DevOps谋求更短的迭代周期、更高频的公布。但公布的次数越多,引入故障的可能性就越大。更多的故障将会升高服务的可用性,进而影响到客户体验。所以,为了保障服务质量,守好公布这个最初一道关,阿里逐渐倒退出了适应DevOps要求的公布策略。 作者 | 沉银起源 | 阿里技术公众号 前言DevOps谋求更短的迭代周期、更高频的公布。但公布的次数越多,引入故障的可能性就越大。更多的故障将会升高服务的可用性,进而影响到客户体验。所以,为了保障服务质量,守好公布这个最初一道关,阿里逐渐倒退出了适应DevOps要求的公布策略。 在开始讲述阿里的实际之前,咱们先简略介绍下几种常见公布策略,以及它们实用的场景和优缺点。 一 常见公布策略1 停机公布停机发布会在公布以前敞开服务,进行用户拜访,而后一次性的降级所有服务。这种公布策略的公布频率往往比拟低,且须要在公布之前做好短缺的测试。 停机公布的特点有: 所有须要降级的组件被整合到一次公布中一个我的项目中的大部分利用都会被更新公布之前的研发流程和测试流程往往须要花很长的工夫公布时如果呈现问题, 修复和回滚的老本很高实现一次停机公布, 须要破费很久的工夫, 且须要很多团队在一起能力实现往往须要客户端和服务器端同步降级停机公布并不适宜互联网公司,因为两次公布的距离很久,从性能个性提出到进入市场的工夫太长,对市场反馈不敏感,会在充沛竞争的市场里处于下风。每次公布因为要停机,也会带来经济损失。 劣势: 简略,不太须要思考新旧版本共存时的兼容性问题劣势: 公布过程中,服务不可用只能在业务低峰期 (往往是夜间)公布,并且须要很多团队在一起工作呈现故障后很难回滚适宜场景: 开发测试环境非关键利用,用户影响面小兼容性比拟难管控的场景2 金丝雀公布金丝雀公布这个术语源自20世纪初期,过后英国的煤矿工人在下井采矿之前,会把笼养的金丝雀携带到矿井中,如果矿井中一氧化碳等有毒气体的浓度过高,在影响矿工之前,金丝雀相比人类体现的更加敏感疾速,金丝雀中毒之后,煤矿工人就晓得该立即撤退。金丝雀公布是在将整个软件的新版本公布给所有用户之前,先公布给局部用户,用实在的客户流量来测试,以保障软件不会呈现重大问题,升高公布危险。 在实践中,金丝雀公布个别会先公布到一个小比例的机器,比方 2% 的服务器做流量验证,而后从中疾速取得反馈,依据反馈决定是扩充公布还是回滚。金丝雀公布通常会联合监控零碎,通过监控指标,察看金丝雀机器的健康状况。如果金丝雀测试通过,则把残余的机器全副升级成新版本,否则回滚代码。 劣势: 对用户体验影响较小,在金丝雀公布过程中,只有大量用户会受影响公布平安可能失去保障劣势: 金丝雀的机器数量比拟少, 有一些问题并不可能裸露进去实用场景: 监控比拟齐备且与公布系统集成3 灰度/滚动公布灰度公布是金丝雀公布的延长,是将公布分成不同的阶段/批次,每个阶段/批次的用户数量逐级减少。如果新版本在以后阶段没有发现问题,就再减少用户数量进入下一个阶段,直至扩大到全副用户。 灰度公布能够减小公布危险,是一种零宕机工夫的公布策略。它通过切换线上并存版本之间的路由权重,逐渐从一个版本切换为另一个版本。整个公布过程会继续比拟长的工夫, 在这段时间内,新旧代码共存,所以在开发过程中,须要思考版本之间的兼容性,新旧代码共存不能影响性能可用性和用户体验。当新版本代码呈现问题时,灰度公布可能比拟快的回滚到老版本的代码上。 联合个性开关等技术,灰度公布能够实现更简单灵便的公布策略。 劣势: 用户体验影响比拟小, 不须要停机公布可能管制公布危险劣势: 公布工夫会比拟长须要简单的公布零碎和负载均衡器须要思考新旧版本共存时的兼容性实用场景: 适宜可用性较高的生产环境公布4 蓝绿公布蓝绿部署是指有两个完全相同的、相互独立的生产环境,一个叫做“蓝环境”,一个叫做“绿环境”。其中,绿环境是用户正在应用的生产环境。当要部署一个新版本的时候,先把这个新版本部署到蓝环境中,而后在蓝环境中运行冒烟测试,以查看新版本是否失常工作。如果测试通过,公布零碎更新路由配置,将用户流量从绿环境导向蓝环境,蓝环境就变成了生产环境。这种切换通常在一秒钟之内就能搞定。如果出了问题,把路由切回到绿环境上,再在蓝环境中调试,找到问题的起因。因而,蓝绿部署能够做到仅仅一次切换,立即就向所有用户推出新版本,新性能对所有用户立即失效可见。 劣势: 降级切换和回退速度十分快零停机工夫有余: 一次性的全量切换,如果公布呈现问题, 会对用户产生比拟大的影响须要两倍的机器资源须要中间件和利用本身反对热备集群的流量切换实用场景: 机器资源比拟充裕或者按需分配 (背靠云厂商)5 A/B 测试A/B 测试和灰度公布十分像,能够从公布的目标上进行辨别。AB测试偏重的是依据A版本和B版本的差别进行决策,最终抉择一个版本进行部署。和灰度公布相比,AB测试更偏向于去决策,和金丝雀公布相比,AB测试在权重和流量的切换上更灵便。 举个例子,某性能有两个实现版本 A 和 B,通过细粒度的流量管制,把 50% 的用户总是疏导到 A 实现上,把剩下的 50% 用户总是疏导到 B 实现上,通过比拟 A 实现和 B 实现的转化率,最终抉择转化率较高的 A 实现作为性能的最终版本。 ...

July 8, 2021 · 1 min · jiezi

关于devops:JFrog-收购-Vdoo-以提供从开发到设备的端到端持续安全

收买在对立的 DevOps 平台中为全类型的软件版本提供新的软件平安产品加利福尼亚州桑尼维尔,2021 年 6 月 29 日 — 流动式软件公司 JFrog Ltd.(“JFrog”)(纳斯达克股票代码:FROG)明天发表已达成最终协定,以收买 Vdoo Connected Trust Ltd.(“Vdoo”) ) 以现金和股票为根底的交易,价值约 3 亿美元。 JFrog 已放慢致力提供行业当先的平安产品,以反对 DevOps 用户应答继续软件交付市场的中断。作为 JFrog 平台的一部分,Vdoo 将通过扩大其端到端 DevOps 平台产品来减速 JFrog 成为所有软件更新背地的公司并创立 Liquid Software 世界的愿景,提供从开发环境始终到边缘、物联网和设施。 Vdoo 的世界级平安专家和破绽钻研人员将退出 JFrog 团队,持续为开发人员和平安工程师开发先进的平安解决方案。凭借在软件架构和破绽钻研、逆向工程和二进制代码剖析方面的多年丰盛教训,Vdoo 的团队和 JFrog 将寻求提供残缺的 DevSecOps 解决方案,以确保整个软件包生命周期的平安。 全面的平安办法满足市场需求,提供疾速平安的软件更新当今的许多 DevOps 解决方案都短少齐全集成到软件生命周期中的适当平安性能。平安工具各不相同,每个工具都有本人的数据集,这在开发团队和平安团队之间造成摩擦,减缓了软件更新的公布——尤其是在继续交付到边缘或跨大量设施时。因而,许多这些平安工具并没有兑现疾速、自动化和平安公布的承诺。 市场须要一个整体流程来爱护软件组件始终到边缘,整合平安数据以进行高效决策,节省时间和资源,并为平安认证版本提供具备最高完整性的端到端交付零碎— 从任何起源到任何端点。 “咱们很快乐 Vdoo 退出 JFrog 小家庭,”JFrog 的联结创始人兼首席执行官 Shlomi Ben Haim 说。 “咱们很分明,扭转软件创立、公布和更新到边缘的形式的独特愿景将成为咱们的指南针,因为咱们为市场提供了一个以二进制为重点的解决方案来爱护他们组织的软件资产。此举将通过咱们的平安解决方案 JFrog Xray 扩充 JFrog 以后的胜利,并发明冀望,即‘无畏的公布’将成为平安和开发团队的体验。” Vdoo 的联结创始人兼首席执行官 Netanel (Nati) Davidi 示意:“这项拟议的收买非常适合咱们两家公司。” “咱们对 DevOps 和平安有一个独特的愿景:如果任何 DevOps 公司不是一家平安公司,那么它只是解决了难题的一小部分。咱们很骄傲咱们的团队始终专一于混合和整体,并在整个软件交付生命周期的各个方面进行集成。咱们期待作为 JFrog 的一部分持续推动 Liquid Software 的使命,并期待联结团队带来扭转行业的翻新。” ...

July 2, 2021 · 2 min · jiezi

关于devops:DevOps成长路线影响地图-IDCF

为了写这篇文章,把无敌哥的视频《买通任脉的影响地图》又看了一遍,麻利无敌的书里也有专门一个章节来介绍。看视频的时候,竟然很多内容都没什么印象了,可见我的记性是有多大。连忙把这两天的学习心得记录下来,省的又遗记了。 从为什么开始(Why)测试小T走到开发小D身边,对小D说,这个性能逻辑有点怪,为什么要这么实现呢?小D眼睛一翻,我只负责实现,至于为什么,你得去问设计。 如何您碰巧也是一位测试,或者项目经理,这样的场景是否很相熟呢?开发人员只关怀how,对于why,很少去想。甚至,他本人也感觉这性能逻辑有点怪,但还是会持续去做。这难道就是事实版的“背道而驰”? 也已经和开发聊过,为什么开发都不怎么关怀业务?失去的答复是,IT技术更新迭代太快了,而且分工越来越细,每个细分畛域都有很多技能要学习。咱们开发,都想把精力放在技术的打磨上,没有太多的精力和趣味去理解业务,再说,不是还有产品经理吗。 听下来也没故障!只是,让我想起了一句话“每个人都感觉本人做的很好,但最终后果却是一团糟”。给大家举个例子。 在20世纪80年代,美国制作受到了德国和日本的微小冲击,尤其是在汽车制作行业,德国和日本的汽车以更优的品质和较好的舒适度迅速霸占了美国市场。令美国厂商百思不得其解的是,美国在生产技术、配备、设计和工艺方面并不比德国和日本差,在汽车制作畛域积攒的工夫甚至超过他们,然而为什么美国汽车的品质和精度就是赶不上人家? 在那个时候,品质治理曾经汽车制作畛域非常遍及了。光学测量被利用在产品线上当前,在零部件生产和车身拆卸的各个工序已积攒大量的测量数据。但问题是,即使测量非常精准,在各个工序和零部件生产和车身拆卸都进行严格的品质管制,然而在组装结束后仍然有较大的误差。于是美国的汽车厂商不得不花大量工夫重复批改和匹配工艺参数,最终的品质却仍然不稳固,时常呈现每一个工序都在品质管制范畴内,但最终的产品质量仍然不能达标。 可见,工业制作早曾经通知咱们,单个阶段的最优化,并不代表整体最优。业务与开发之间的隔膜,怎么破?如何预防“背道而驰”? 干系人(Who)指标定好了,能够通过谁的行为来达成这个指标呢?很显然,须要业务和开发本身去扭转行为,其余干系人一起协同,比方Scrum Master。 影响(How)干系人的行为应如何来扭转?如何帮忙咱们达成指标? 对于不同的干系人(Actors),别离列出各自的行为。假如通过这些行为,指标就能实现。 交付物(What)须要做什么来反对影响的实现,也就是说须要交付什么性能。 咱们假如,交付物如果可能提供图中列的这些性能,比方可视化指标和性能的关系,共享全景视图,最短门路,助力思维转变,就能促使各干系人去采取相应的口头,最终达成指标。 这个交付物是什么呢?置信大家都曾经猜出来了,没错,它就是影响地图。用来解决文中提到的2个问题: 业务指标与性能之间映射关系的含糊和不统一。业务职能和开发职能之间交换决策的隔膜。 总结(Summary)影响地图这个工具,个别用来做战略规划,产品布局等。本文利用影响地图来解释影响地图自身,介绍了影响地图中四个关键字(why,who,how,what)的根本含意。图中我列出的how和what条目,只作为举例用,并不残缺。影响地图里很重要的一点就是“永远不要执行完影响地图中的所有What”,因为所有的事项,都是基于假如,只有找出最短门路,而后去疾速验证。等验证完了,后面的某些假如,可能曾经生效了。所以每验证一次,就要从新评估每个假如,而后开始新一轮验证。 起源:侬家铺子 作者:侬家铺子申明:文章取得作者受权在IDCF社区公众号(devopshub)转发。优质内容共享给思否平台的技术伙伴,如原作者有其余思考请分割小编删除,致谢。 IDCF DevOps黑客马拉松,独创端到端DevOps体验,精益守业+麻利开发+DevOps流水线的完满联合,2021年仅有的3场公开课,数千人参加并统一五星举荐的金牌训练营,谋求卓越的你肯定不能错过!关注公众号回复“黑马”即可报名 北京:7月24-25日上海:9月11-12日深圳:11月20-21日

July 1, 2021 · 1 min · jiezi

关于devops:如何使用Nginx对Artifactory进行http应用

在咱们日常应用高可用集群时,都会应用到负载平衡工具对多个节点的负载进行转发。这里就不得不提到咱们罕用的一个负载平衡工具Nginx,Nginx官网提供的收费版本性能绝对简略,大部分状况下咱们都是用其进行负载平衡,对于利用的状态次要是依赖于其余的监控工具。如果对于小型的团队来说,部署专门的监控工具还须要资源,应用Nginx对利用进行探活监控能够节约这部分老本。首先装置Nginx应用yum装置nginx我这里应用的是1.16.1版本yum install nginx装置实现后能够获取源码装置命令nginx -V装置Nginx探活插件下载源码与探活插件wget https://nginx.org/download/ng...wget https://github.com/yaoweibin/...Nginx应用源码编译装置相干的依赖包yum install pcre pcre-devel openssl openssl-devel gd gd-devel zlib patch libxml2-devel libxslt-devel perl-devel perl-ExtUtils-Embed perl zlib-devel patch解压源码和插件包,我这里将两个软件包全副放到/opt上面进行解压tar zxvf nginx-1.16.1.tar.gzunzip nginx_upstream_check_module.zippatch探活插件到Nginx源码中cd /opt/nginx-1.16.1patch -p1 < /opt/nginx_upstream_check_module-master/check_1.16.1+.patch执行源码编译装置,增加http探活插件./configure \--prefix=/usr/share/nginx \--sbin-path=/usr/sbin/nginx \--modules-path=/usr/lib64/nginx/modules \--conf-path=/etc/nginx/nginx.conf \--error-log-path=/var/log/nginx/error.log \--http-log-path=/var/log/nginx/access.log \--http-client-body-temp-path=/var/lib/nginx/tmp/client_body \--http-proxy-temp-path=/var/lib/nginx/tmp/proxy \--http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi \--http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi \--http-scgi-temp-path=/var/lib/nginx/tmp/scgi \--pid-path=/run/nginx.pid \--lock-path=/run/lock/subsys/nginx \--user=nginx \--group=nginx \--with-file-aio \--with-ipv6 \--with-http_ssl_module \--with-http_v2_module \--with-http_realip_module \--with-stream_ssl_preread_module \--with-http_addition_module \--with-http_xslt_module=dynamic \--with-http_image_filter_module=dynamic \--with-http_sub_module \--with-http_dav_module \--with-http_flv_module \--with-http_mp4_module \--with-http_gunzip_module \--with-http_gzip_static_module \--with-http_random_index_module \--with-http_secure_link_module \--with-http_degradation_module \--with-http_slice_module \--with-http_stub_status_module \--with-http_perl_module=dynamic \--with-http_auth_request_module \--with-mail=dynamic \--with-mail_ssl_module \--with-pcre \--with-pcre-jit \--with-stream=dynamic \--with-stream_ssl_module \--with-debug \--with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' \--with-ld-opt='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E' \--add-module=/opt/nginx_upstream_check_module-master/应用Nginx负载ArtifactoryNginx能够作为Artifactory制品库的负载均衡器,用来负载Artifactory多个节点间的申请,Artifactory也能够主动生成Nginx配置文件,具体操作参考下图配置探活生成配置文件后,应用探活插件的配置办法,在Nginx的config 文件中进行配置。具体样例如下:upstream artifactory {server 192.168.1.2:8082;server 192.168.1.3:8082; ...

June 18, 2021 · 1 min · jiezi

关于devops:运行状况检查

为了在服务器运行中放弃很高的可靠性,咱们能够采纳一些办法来及时处理各种可预测的故障。比方,各种硬件都会有肯定的寿命预期,任何软件也有可能在某个时刻解体。现实情况下,咱们心愿服务的运行状况只有两种状态 失常工作不失常工作但不会影响其余服务然而事实上当某个服务产生故障时,可能会对整个零碎造成极大的影响。通过运行状况查看(health check), 咱们能够检测单机故障,从而能够及时对机器进行主动替换或是及时告诉到SDE。然而执行health check也有可能将小问题转变为全面的大的中断。因而在增加这种查看时须要权衡利弊。 Whathealth check是一种询问特定服务器上的服务是否胜利执行的工作办法。LB能够定期向服务器收回询问申请,以确定能够平安的将流量导向哪些服务器。如果服务是从queue中轮询音讯,那么在轮询前能够先查看本人是否运行状况良好,再决定是否从queue中取出更多的工作。Monitoring agents(能够在每台机器上运行或在内部监控fleet中运行)也能够用来询问服务器是否运行良好,而后决定是收回警报还是主动解决产生故障的服务器。 health check能够解决least request负载平衡算法存在的black hole问题。 How现实的health check须要查看利用程序运行的方方面面,包含非关键反对过程是否正在运行。然而如果因为非关键起因使得health check失败,从而将该台服务器从可用服务器中移除,那么这种机制会弊大于利。health check的难点在于,执行全面的health check,可能会导致查看过细,使得本应该还对付可用的服务器间接被停用,导致给整个fleet造成侵害。而过于拉垮的health check则起不到本应该起的作用。另一方面,误报故障会给整个fleet造成侵害。因而,如果单台服务器产生某个问题,则可用将其停用,但如果所有服务器“产生”同样的问题,则应该容许流量持续通过。这种机制称为Fail open。咱们能够简略的将health check分为 shallow health check和 deep health check。 shallow health check示意的是本机器的问题,覆盖范围仅仅是单台机器。比方读写查看,机器磁盘是否满了,满了能够主动换机器;bean有没有启动胜利等。deep health check示意的是与其余机器相干的health check,比方对于依赖项的查看等。执行health check时要满足的一些条件: 机群应该采取大致相同的行为模式,比方将不同类型的流量路由到不同机器即违反了此条。队列应该同构,即应该应用大致相同的机器。必须报告谬误或行为差别。因为咱们依附服务器自身来报告谬误,因而如果它们的监控零碎也产生了问题,就很麻烦。因而咱们能够将查看增加到会拜访服务器的客户端,比方Load Balancer,在LB上能够查看日志,从而晓得每个申请都发往了哪个后端服务器,响应工夫,以及该申请胜利还是失败。tips:优先执行health check!衡量依赖项查看与影响范畴,比方有的依赖项并不是服务的要害依赖项,这种货色失败就失败了,不要因而而使得health check失败,导致服务不可用。或者一个service上有多个API,其中一个API不可用了,但其余API可能能够失常应用,是否要在这种状况下齐全停用该机器上的服务,须要慎重考虑。

June 1, 2021 · 1 min · jiezi

关于devops:Debug

为什么要进行检测在检测的过程中一方面能够帮忙咱们了解咱们的零碎,更重要的是,这能够为客户提供卓越经营的体验。帮忙咱们更理解咱们给客户的体验是什么样的。在amazon.com购物时,高提早会对客户造成十分差的购物体验,从而升高转换率。对应用AWS的用户,他们须要的是高可用性和低提早。在Amazon,咱们不仅仅去思考均匀提早,而是会去更加关注提早的异样值。比方P99.9或是P99.99这样的指标。之所以这样,是因为在升高P99之后,均匀提早也同样会升高,然而升高了均匀提早,P99并不一定会升高。更加关注高百分位提早的一个起因是,某个服务中的高提早可能会在其余服务中产生乘法效应。即,如果调用链深处的服务的latency减少,最终用户可能会感触到很长的提早。Amazon的大型零碎是由许多协同工作的服务组成。每个服务都由一支独自的团队开发和经营。领有服务的团队称为service owner. 无论负责任何职位,该团队的每个成员均会像服务的owner护额operator一样思考。作为service owner,团队会设定领有的每个service的经营绩效相干的指标。团队还须要确保能够看到service的运行状况,以保障咱们达成这些指标、解决呈现的任何问题和促使本人在第二年达成更高的指标。为了设定指标和取得这种可见性,团队必须对系统进行检测。检测还促使咱们可能有策略的探测和应答经营事件。Instrumentation feeds data into operational dashboard, so that operators can view real-time metrics. It also feeds data into alarms. 运营者应用具体的检测输入疾速诊断出错的起因,这样一来,咱们能够迅速想方法先临时缓解问题,并记下该问题,之后进行解决,避免该问题再次复发。Without good instrumentation throughout the code, we sink precious time into diagnosing problems. 检测什么为了取得必须的metrics,service owner必须从多个方面掂量operational performance,以便从多个角度理解各组件的端到端具体表现。比方,customer通过Load Balancer调用某个service,该服务会与remote cache和remote database通信。We want each component to emit metrics about its behavior. We also want metrics on how each component perceives the behavior of other components. 将来自所有这些角度的metrics会集起来时,service owner就能迅速查明问题的root cause。许多AWS服务都会主动提供一些resource的经营倡议。例如,DDB提供无关成功率,错误率和提早的Amazon CloudWatch metrics。然而,当咱们构建应用这些服务的零碎时,咱们须要取得高得多的visibility,以便理解零碎的具体表现。检测须要显示代码来记录工作要执行多长时间,某些代码门路多久执行一次,与工作执行的工作相干的元数据和工作的那些局部胜利或失败。如果团队未增加显式检测,则service owner将被迫把本人的服务作为黑盒来经营。 ...

May 30, 2021 · 5 min · jiezi

关于devops:多服务在系统中的公平性

咱们能够通过对API速率限度来管理系统申请,避免过载。 Service-oriented architecture(SOA,面向服务的架构)具备十分清晰的权责划分,以及使零碎之间耦合尽量涣散。 偏心bin-packing algorithms执行 placement algorithms 以在 fleet 中找到一个spot来运行新的workload。(相似于找到一个有足够容量来搁置workload的bin)继续监控每个workload和每个server的 utilization 来挪动workload。(相似于在bins之间挪动workload以确保没有bin过满)监控整个fleet utilization,并依据须要减少或者缩小capacity。(相似于在所有bins都行将装满之前减少新的bin,或者在他们都行将为空时缩小bin)只有零碎没有失去充沛的利用,就能够使工作负载超出硬调配的边界,并在零碎失去充分利用时将工作负载放弃在边界之内。(相似于容许workloads在每个bin中扩大,只有他们不会挤出其余workloads即可)先进的算法联合了下面这些技术,比方一个fairness system能够monitor每个workload,评估是否有任何两个workloads能够充分利用某些的资源,之后将它们挪动到一个bin中。只有一个workload没有充分利用其调配的资源,同一个bin中的另一个workload就能够借用这些资源。在借用资源的时候,工作负载无需留神借用。如果工作负载须要应用所有调配的资源,则返回这些借用资源的工夫简直是刹时的。另外,workload须要能够在bins之间疾速挪动。如果一个忙碌的workload习惯于通过从其街坊那里借用超出其已调配的资源,然而其街坊扭转了其行为并开始应用其更多的已调配资源,则须要将繁忙的workload移至另一个bin。 通过Load shedding减少偏心通常来说,随着零碎负载的减少,零碎应该主动进行扩大。最简略的办法是减少capacity并进行程度扩大。而对于像是基于AWS Lambda构建的无服务器架构的服务,因为可按需分配容量来解决工作,因而简直能够即时进行程度扩大。对于有服务器服务,主动扩大就须要更长时间了。 通常对扩大的工夫要求在几分钟之内即可,然而,如果服务器上的负载减少快于Auto Scaling,则咱们须要采纳疾速故障策略,减去多余负载,这样能够为解决到的申请保持一致的性能。这样做的益处在于,零碎的所有咱们都是可预测的。 通常咱们会将服务设计为尽快将不能解决的申请返回给客户端,以最大水平的缩小服务器执行的工作量。然而这样会造成单机黑洞,因为相应快,而导致负载均衡器将更多的申请发送过去,因而咱们须要成心加快疾速谬误的响应速度,以匹配胜利响应的提早。 通常来自多个客户端的负载是不相干的,因而如果服务的总负载忽然减少,很有可能是由单个客户端所引起的。出于均衡思考,咱们须要防止因为单个客户端的计划外负载而导致所有客户端中都呈现申请失败的景象。对于这种状况,咱们应用速率限度来限度计划外的流量增长。能够为每个client设定某个额度的资源和操作的最大值。这样,如果多客户端服务遇到了计划外的负载减少,则该工作负载的计划外局部将被回绝,其余工作负载将持续以可预测的性能运行。 然而配额的应用会缩小服务的可用性,当一个客户端的工作量超过其配额时,它将开始看到其多余的申请失败。然而实际上,该服务可能具备满足这些申请的能力。 通常会以 429 状态码返回 “超出API速率限度”响应。 状态码在500-599范畴内意味着服务器因为某种原因而失败状态码在400-499范畴内意味着客户端正在做意外的事件,在本文所述的状况下,是计划外的API调用量Note: 在理论利用时,会发现某些服务实际上为超出速率返回503状态码,这是因为2012年RFC 6585才正式将429状态码退出到HTTP标准中。因为为了放弃 backward compatibility ,很多服务其实会对“超出API速率限度”返回503。 深刻配额服务所有者通常会为每个client配置配额。例如,对于AWS服务,Client通常是一个AWS account。有时,配额会放在比client更细粒度的地位上,例如放在Service领有的特定资源上,比方DynamoDB表。服务的所有者须要定义规定,为每个调用者提供默认的quota。或者如果client预期行将呈现的负载减少,则他们须要要求服务减少其配额。 quota的品种: the number of things the client can have running at the same time.例如Amazon EC2为特定AWS account能够启动的实例数量施行配额。rate-based quota. 基于比率的配额通常以 “每秒申请数” 这样的单位进行掂量。本文次要着重于基于比率的配额,但文中的探讨在另一种配额中也大体适当。下图演示了配额的应用。它显示了具备无限容量的服务(通过百分比显示)。该服务具备三个客户端。该服务已为每个客户端调配了其总容量的1/3.该图显示客户端Blue试图超过其预调配的吞吐量,然而未能胜利,对其余客户端对服务的调用也未造成影响。 为了使可预测性更高,以及不便客户端更加理解调用,服务端能够为客户端提供可查看和应用的指标,以在其使用率靠近最大配额时收回警报。例如,DynamoDB公布Amazon CloudWatch指标,该metric显示为表配置的吞吐量,以及该吞吐量和工夫的关系。 某些API的服务老本远高于其余API。因而,服务可能会为每个客户端调配较少的低廉API配额。同样,服务端并非总是事后晓得操作老本。例如,返回单个1KB的行查问比返回1MB的行查问便宜。分页能够避免这种开销过于失控,然而最小页面大小和最大页面大小之间依然可能存在老本差别,这使设置正确的阈值非常具备挑战性。为了解决此类问题,某些服务将较大的申请视为多个申请。此技术的实现形式是,将每个申请视为最便宜的申请,而后在API调用实现后,依据实在的申请老本返回,并记录为客户端的配额。 施行配额须要有肯定的灵活性。例如:Client A的配额为每秒1000个事务(1000TPS),然而该服务曾经扩大为能够解决10000TPS,并且该服务以后其所有客户端总共状况为5000TPS(并非总配额为5000TPS!)。如果Client A从500TPS飙升至3000TPS,则2000TPS将被回绝,然而服务理论足够解决这些申请。这时咱们能够让服务容许这些申请。如果之后其余client也同时应用更多配额,则该服务能够开始“删除”client A的超出配额的申请。对于这种“计划外配额”,应该及时向客户端发出信号,让client晓得它曾经超出配额,并且在不可预感的将来会有产生谬误的危险。同时,该服务应该晓得它可能须要扩大其fleet,并且能够肯定水平上主动减少client A的配额。 下图演示了这种状况。图中创立了一个相似于上图用于显示向其client硬调配配额的服务的图表。然而,在下图中,服务为其client的配额减少了灵活性,而不是对其进行硬调配。stack容许客户端应用为利用的服务容量。因为橙色和灰色为应用满其配额,因而容许蓝色超出其预配置的阈值并利用未应用的容量。如果橙色或灰色决定应用其容量,则其流量必须优先于蓝色的突发流量。 在Amazon,有通过思考客户的理论用例来钻研灵活性和突发性。例如,EC2 instance(及其负载的EBS卷)在启动实例时通常比当前更忙。这是因为启动实例时,须要下载并启动其操作系统和应用程序的代码。当咱们思考到这种流量模式时,咱们发现咱们能够更慷慨的应用后期突发配额。这样能够缩小启动工夫,并且依然提供了咱们的长期容量布局工具,以确保工作负载之间的偏心。 还能够思考配额是否能够随工夫变动。例如,某些服务会随着客户的增长主动减少其配额。然而,在某些状况下,客户须要并依赖固定配额,例如,用于管制老本的配额。 配额有时候并不一定是爱护机制,而是服务的性能。 对准入控制系统的设计决定流量大小,缩小负载,施行基于速率的配额的零碎称为 admission control systems。 ...

May 29, 2021 · 2 min · jiezi

关于devops:Google-和腾讯为什么都采用主干开发模式

摘要本文介绍了两种罕用的代码分支模式:个性分支开发模式、骨干开发模式,别离论述了其优缺点和实用环境;同时分析了 Google 和腾讯采纳骨干开发模式的背景和决策因素,捎带分享了这2个巨头的实际,供读者在技术选型中参考。 背景按之前的写作思路,本文应该叫《Google 工程效力三板斧之三:骨干开发》,但我扭转了主见,心愿能同时提供国内互联网公司的实际,供读者参考,因而文章题目也随之更改。 软件开发过程中,开发人员通过版本管理工具对源码进行存储,追踪目录和文件的批改历史。为了区隔不同状态的源代码,会采纳分支进行治理。不同的软件开发模式,对应着不同的分支模式。 软件业界罕用的软件分支模式有多种,但实质上能够分为两类: 骨干开发模式(Trunk Based Development)个性分支开发模式(Feature Branch Development)两种模式的定义及优缺点剖析个性分支开发模式个性分支开发模式是指为一个或多个特定的需要/缺点/工作创立代码分支(branch),在其上实现相应的开发(个别通过增量测试)后,把它合并(merge)到骨干/集成分支的开发模式。 通常这种分支生命期会继续一段时间,从几天到几周不等,极少数状况甚至以月算。 个性分支开发模式中罕用的有 Git-Flow 模式、Github-Flow 模式和 Gitlab-Flow 模式等。这些模式只有细节上的差别,以 Git-Flow为例: 长处: 个性开发周期宽松:因为生命期能够较长,较大的需要个性能够在宽松的工夫内实现再合入主干;分支测试的工夫宽松:因为生命期能够较长,能够有较多工夫对分支进行测试,甚至手工测试;毛病: 分支治理简单:起因在于大量采纳代码分支,且起源分支和合入指标分支各异,操作简单 —— 以上图为例,能够从master(Tag 1.0.0) 拉出 hotfix 1.0.2 分支,而后合入到 develop 分支,开发阶段完结后合入到 release branches,公布后合入 master,非常复杂,很容易出错;合并抵触多、解决难:分支生命期越长,意味着与骨干的代码差别越大,抵触概率越高,抵触的解决难度越大(甚至成为不可能);迭代速度慢:个性分支生命期长(数天至数周)意味着个性上线速度慢,相应的迭代速度也慢;须要较多测试环境:每个个性分支都须要调配至多1个测试环境,且长期占用(有状态);实用环境: 对版本迭代速度要求不高测试自动化水平低,或说次要靠人工测试的骨干开发模式骨干开发,是指开发人员间接向骨干(习惯上骨干分支通常为:trunk 或 master)提交/推送代码。通常,开发团队的成员1天至多1次地将代码提交到骨干分支。在达到公布条件时,从骨干拉出公布分支(通常为 release),用于公布。若发现缺点,间接在骨干上修复,并依据须要 cherry pick 到对应版本的公布分支。 流程: 长处: 分支模型简略高效,开发人员易于把握不容易呈现错误操作防止了分支合并、抵触解决的困扰随时领有可公布的版本有利于继续集成和继续交付毛病: 基础架构要求高:合入到骨干的代码若品质不过关将间接阻塞整个团队的开发工作,因而须要高效的继续集成平台进行把关;自动化测试要求高:需有齐备单元测试代码,确保在代码合入主干前能在取得疾速和牢靠的品质反馈;最好有代码评审:若代码品质要求高,须要配套代码评审(CR)机制,在代码提交到骨干时,触发CR,通过 Peer Review 后能力正式合入;最好有个性开关:骨干开发频发合入主干的状况下,个性拆分得很小,可能是半成品个性,须要配套个性开关(Feature Toggle),只有当个性整体开发完才通过灰度公布等伎俩逐渐关上;实用环境: 对迭代速度要求高,心愿需要疾速交付上线基础架构强,继续集成工具高效;团队成员习惯TDD(测试驱动开发),代码自动化测试覆盖率高(至多增量代码的自动化测试覆盖率高);为什么 Google 和腾讯采纳骨干开发模式互联网巨头 Google 大部分业务开发都采纳骨干开发模式,国内巨头腾讯也在推广骨干开发(试点业务团队大部分曾经采纳)。 他们采纳骨干开发的起因在于对骨干开发的长处有强烈诉求,而且有能力和资源补救其毛病: 都是互联网企业,竞争强烈,因而对迭代速度要求高;基础架构能力强:都能自研弱小的继续集成平台,Google 有自研的 Forge,腾讯有自研的蓝盾;自动化测试能力强:都推广TDD,强调开发负责品质,缩小甚至勾销手工测试人员(大量必要的手工测试转外包),自动化测试覆盖率高;都有严格的CR机制确保代码品质:Google 极其严苛的可读性认证(Readability)在业界曾经是标杆,腾讯是国内少有正在采纳相似实际的互联网企业。严格的代码可读性认证和依据此规范执行的严格代码评审制度,能无效的保障合入主干的代码品质不会升高。骨干开发的最大长处是:效率和品质,而这2者是软件和互联网企业的外围诉求。骨干开发的毛病,巨头有能力和资源来填平这些坑。 因而,从ROI(Ratio of Investment)的角度来看,Google 和腾讯采纳骨干开发实属必然。 美中两巨头的实际Google 在骨干开发的实际咱们在之前的文章提到,Google 的工程效力(也叫研发效力)核心理念只有简略的3条: 应用单体代码仓库(参考:Google 工程效力三板斧之一:单体代码仓库)应用 Bazel 构建(参考:Google 工程效力三板斧之二:应用 Bazel 构建)骨干开发;其中的第3条,就是本文所述内容。 ...

May 20, 2021 · 1 min · jiezi

关于devops:采用DevOps的7个主要障碍你一定不知道

DevOps在2018年庆贺了它的十周年纪念日,在科技行业,这曾经是足够漫长的生命周期了。只管DevOps曾经绝对成熟,DevOps哲学依然在回避甚至是最驰名和最有资源的组织。一份令人震惊的Gartner报告显示,75%的DevOps我的项目未能实现其指标。 为什么DevOps的失败率如此之高?在施行DevOps理念时,组织面临的独特挑战是什么?如何克服这些挑战? 本篇文章将解决这些问题,并为企业提供可复制的策略,以进步DevOps打算的成功率。 1.资源配置不标准资源分配是DevOps的一大挑战。仅仅集成开发和运维团队并不能产生一个高效的DevOps团队。极大数量的DevOps团队不足主题专家,这重大影响了团队实现DevOps承诺的能力。 首先,从事利用程序开发、优化和监控等不同技术的多面手不会像专家那样有效率。这样会节约贵重的工夫,最终减慢DevOps的交付速度。 此外,当DevOps团队最小化计划外工作时,他们的工作效率最高。如果没有专门的资源来解决特定的DevOps问题,团队被迫将简单的问题调配给非主题问题的专家。这将毁坏他们的工作打算,并使整个团队效率低下。更重要的是,这类人才日益减少的工作量减少将导致员工精疲力竭,并有可能使整个DevOps打算脱轨。 只有在有专门人才解决问题时,DevOps能力放慢性能公布、更新和上市工夫。因而,企业必须确定要害的应用程序技术和开发流程,这些技术和流程能够通过DevOps进行优化,并为这些特定畛域调配专门的技能型人才。 最佳的资源分配对于DevOps打算的胜利至关重要。 2.责任错位DevOps将指标截然不同的团队汇集在一起,在一个“不稳固的”环境中工作。开发人员次要关怀的是翻新、稳固的运维团队、性能完满的QA团队等等。当然,这些团队之间必然会有摩擦和抵触。 更蹩脚的是,高层往往不会明确定义DevOps团队的指标、职责和优先级。这给不置可否留下了很大的空间。习惯于孤岛式工作而不放心依赖关系的团队会倒退到原来的工作形式,从而否定了所有实现无缝合作的致力。 在扭转领导者之前,让团队走出思维定势是最大的挑战。因而,当团队由跨学科资源组成时,DevOps的工作成果最好。领有运维思维的开发人员,他们不羞于常常走出本人的舒服区,这是引领DevOps打算走向胜利的迫切需要。 组织通常通过清晰地形容DevOps的指标、优先级和职责来克服这些挑战。更重要的是,他们为DevOps工作的胜利调配了残缺的责任。每个团队成员都对DevOps端到端工作的胜利负责。当他们的集体体现由团队的整体胜利来掂量时,筒仓会主动合成,合作会迅速减少。 3.过程割裂没有多少DevOps领导者意识到,或者至多意识到,DevOps是十分扩散的。只管DevOps曾经成熟,但它并不是特地实用于中小企业软件开发和交付模式。DevOps长期以来次要是一个大型企业打算。因为这个起因,与DevOps接轨的中小企业发现自己陷入了窘境。 DevOps通过自动化软件开发生命周期中波及的大部分工作来工作。然而,没有一个工具、过程或资源能够实现这一点。DevOps团队必须应用不同的工具来自动化其操作的不同方面。有很好的工具能够自动化各个组件,比方继续集成、基础设施供给、测试、源代码管制等等。然而,这些工具之间彼此不能集成(当然,也可借助工具实现集成,如禅道ZTF买通了禅道和Jenkins之间的沟壑,贯通DevOps继续集成、继续测试、继续部署等DevOps生命周期的不同阶段)。 使这些不同的工具互相通信须要大量的资源,而大多数组织无奈或违心调配这些资源。因为这个起因,DevOps团队常常被迫应用无限的自动化性能,这是DevOps的对立面。 高效的DevOps团队在执行工作和自动化工作之间调配工夫。如果没有自动化,事务性工作会逐步减少,导致员工精疲力尽、流程提早、响应能力好转和交付品质降落。 企业能够通过开发一个清晰的DevOps策略来防止这些问题,该策略指定组织的DevOps指标,确定能够自动化的流程,并部署资源来实现这些指标。这些指标应该与资源分配相匹配,这种解决碎片整顿的事实办法将帮忙企业简化和自动化对他们来说很重要的流程。 4.不足适当的度量规范短少适当的度量规范既是一个过程挑战,也是一个人员挑战。KPI和指标在向DevOps团队传播组织的优先级和冀望方面大有帮忙。正如后面所探讨的,稳定性和部署工夫在DevOps团队中继续存在抵触。是应该以就义稳定性为代价匆忙交付,还是重视稳定性提早交付?是如何开始优先思考一个指标而不是另一个指标的? 指标为团队提供了明确而精准的方向,以确定不同指标的优先级。只管这些指标的价值可能会随着业务的不同而变动,但这些指标自身对所有DevOps团队都是广泛相干的。以下是企业在向团队传播DevOps指标时必须定义的一些指标: ● 部署频率● 部署工夫● 更改故障率● 自动测试通过率● 每次公布后的故障数● 缺点逃逸率● 检测的工夫到● 性能应用● 终端用户体验● 业务影响● 部署失败 5.文化转变对改革的抵制将是DevOps转型的最大阻碍。DevOps试图将控制权从各自为政的团队及其负责人转移到组织内的单个多部门机构。天然,这样的尝试能够被解读为对决策权的侵蚀。 更进一步说,这不齐全是对于管制。与传统的IT角色相比,DevOps的领导角色有很大的不同。一般来说,IT领导层必须具备在各种技术方面领导、反对和倡议员工的专业技能。在DevOps环境中,状况并非如此。DevOps的员工工作在一个不稳固和疾速倒退的环境中。谬误是常见的,而带来的结果可能是灾难性的。这样就不难理解为什么员工会放心DevOps流程。 因而,领导的首要作用是发明造就条件,给予员工更高的自由度,爱护他们免受疾速试验带来的挫折。此外,领导者的工作必须集中在确定DevOps的胜利模式,并复制这些模式,以在整个组织中扩大转换。 一个自上而下的办法试图从新定义领导的角色,赋予DevOps团队更多的试验自在,并确保他们的稳定性,这对于克服文化惯性至关重要。 “无奈施行文化改革——整个组织的相干方必须统一反对胜利采纳DevOps所需的必要文化改革。它包含不同组内的执行人员和领导。这不仅仅是技术上的采纳。为了胜利,业务、经营、IT、财务和其余方面必须承诺并建设信赖。”——Ian Willoughby,云解决方案副总裁兼首席架构师 6.无奈扩大DevOps很多时候,晚期DevOps打算的胜利往往会变成失败。体现最好的DevOps团队被更多的我的项目吞没,这很快就会成为我的项目交付的瓶颈,更不用说随之而来的压力减少和生产力降落了。 解决这个问题的一个显著的办法是扩大DevOps团队。然而,这说起来容易做起来难。DevOps专家须要与开发人员或工程师截然不同的技能,因而雇佣起来既艰难又低廉。 一些组织通过在每个开发团队中嵌入一个DevOps专家来克服这个挑战。他们的职责是简化各自团队的交付链,同时与其余部门的DevOps专家进行协调。然而,这种办法常常会在团队之间滋生不统一和合作的麻烦。解决这些新问题的一种办法是借鉴开源实际,应用一种外部源代码办法。 团队必须领有弱小的合作工具,使他们可能从世界任何中央进行编码、公布和合作。最初,要用强壮的、去中心化的“以产品为核心”的交付模型取代传统的“以我的项目为核心”的办法。 “由DevOps驱动的扭转首先须要有一个让人服气的目标。而后,要胜利地掂量变动,须要整个组织的沟通、合作和承诺。”——Qasim Khan,高级副总裁-商业信息官,美国银行 7.无奈合并安全性纯正从外表上看,DevOps和安全性仿佛齐全抵触。DevOps的外围是速度和继续交付,而安全性则强调宽泛的测试和防误。然而,企业正缓缓意识到,与安全性集成的DevOps能够帮忙他们修补破绽、公布更新,并比以往更快地应答网络威逼。 目前,DevOps在将平安集成到其过程中面临三个阻碍:迟缓的开发速度、无穷无尽的平安规范和对可见性的威逼。 最初,通过向所有团队成员提供平安数据并不便他们报告,能够进步威逼可见性。依据每个团队成员的角色和职责定制的SIEM仪表板能够在很大水平上为DevOps团队提供威逼可见性。为了使之无效,能够建设一个基于独特绩效指标的处分体系。 每个组织的DevOps打算都会遇到该组织特有的简单阻碍。然而,关注团队成员的单干和稳固能够缩小外部阻力,并将潜在的惰性起源转变为对领导层的改革,从而确保胜利。

May 20, 2021 · 1 min · jiezi

关于devops:三大业界大佬的DevOps解决方案

 DevOps 在商业界的一些解决方案,次要包含: 微软公司的 Azure DevOps亚马逊公司的 Aws DevOps阿里云的 云效 DevOpsAzure DevOps Azure DevOps 也称为 Microsoft Visual Studio 团队服务(VSTS)。它是为云构建的一组合作开发工具。 VSTS 通常被用作独立术语,Azure DevOps 是一个由几种不同产品组成的平台,例如: Azure 测试计划Azure 看板Azure 存储库Azure 流水线Azure 制品 Azure DevOps是将创意转化为工作软件所需的所有。您能够应用 Azure 工具打算我的项目。 Azure 流水线是 Azure DevOps 的 CI 组件。Azure 流水线是微软的云原生间断集成服务器,它使团队能够从云中间断构建、测试和部署所有组件。Azure 流水线能够连贯到任意数量的源代码存储库,例如 Azure Repos、GitHub、Tests,以获取代码和制品以进行利用交付。 Azure DevOps 服务器 Azure DevOps Server 是微软的一个产品,提供版本控制、需要治理、报告、软件库治理、项目管理、测试、主动生成和公布治理性能。它涵盖了利用的整个生命周期,并启用了 DevOps 性能。 Azure DevOps 能够用作泛滥集成开发环境的后端,但针对 Microsoft Visual Studio 和 Eclipse 的所有平台上进行了定制。 Azure DevOps 服务 微软发表在 Microsoft Azure 平台上公布该软件即 Visual Studio 的服务产品,过后微软将其称为在线Visual Studio。 ...

May 17, 2021 · 1 min · jiezi

关于devops:从价值流图分析研发效能

什么是价值流 传统的工作中,不同的职位都只关注本人所交付的货色,比方产品经理关注产品需要文档的交付,开发人员关注软件代码的交付,运维人员关注于软件产品的部署。 随着DevOps与麻利的倒退,它们越来越强调交付整体价值,而不是繁多角色的交付内容。 因而,价值流的意义就体现进去了。价值流是DevOps的要害概念之一。 依据《DevOps精要》的解释,咱们能够从发明价值以响应客户申请的角度,来考虑一下组织中的工作。实现申请所须要施行的相干口头,能够按顺序排列起来,这称为价值流。 什么是价值流图价值流图就是可视化的价值流。 它大略长下图的样子。 如何画价值流图画价值流图其实很简略: 辨认解决申请的关键步骤剖析每个关键步骤所需的3个度量数据 前置工夫 Lead Time,LT解决工夫 Process Time,PT完成度与准确度百分比 the Percent Complete and Accurate,%C/A将这些步骤组织为一个发明预期后果的流动序列价值流图画好之后,最有价值的信息是流中每个步骤的3个度量数据,即前置工夫(Lead Time,LT)、解决工夫(Process Time,PT)及 残缺度与准确度百分比(the Percent Complete and Accurate,%C/A)。 前置工夫 前置工夫是供应链治理中的一个术语,是指从洽购方开始下单订购到供应商交货所距离的工夫。 对应到咱们的软件开发中,则是指一个工作从创立到实现的工夫。如下图所示。 解决工夫 解决工夫指的是一个工作从开始做到实现所需的工夫。如下图所示。 残缺度与准确度百分比 一个工作实现了并不意味着它是精确的。 举个很简略的例子,咱们读书的时候写作业,通常咱们都能100%的实现,但并不能百分百的正确。 这在软件开发中也十分常见,一个需要被实现了,但和最后的形容并不统一。 通过残缺度与准确度百分比(%C/A)能够剖析我的项目的返工老本。 画价值流图的几个tips: 不要适度细化关键步骤,大抵能够依照看板上的列一一对应或略多。倡议关键步骤数量不要超过15个。能够按有沉积或因为期待而产生提早来画每个步骤。实际中,计算这些度量的数值是一个很大的挑战。一个比拟可行的做法是取每个迭代的几张卡,而后计算PT的平均值。LT则看它从上一步移动到下一步期待了多少天,也取平均值。%C/A则难免会拍脑袋失去数值了,这不可避免。某个要害会议也能够是步骤之一。比方公布评审会。实在案例剖析价值流图上面这张价值流图是来自我一个实在的案例。 对于这个图上的数据我做一些阐明: 不是所有公司的要害流程都长这个样子,公司不同我的项目不同,画进去的价值流图也不同。设计审核的%C/A只有60%是因为过后这个我的项目的产品经理设计原型的时候并没有频繁和业务方沟通,导致设计的货色审核的时候常常返工。软件开发的LT有12天那么长,是因为很多卡ready了之后,须要期待排进某个迭代,所以均匀等待时间有7天。这个数字在很多公司可能更长。公布申请和公布上线的LT都挺长的,也是因为申请须要期待领导审批,公布须要排期,所以等待时间也挺长。用户验收测试的%C/A只有70%也是因为开发过程中并没有频繁获取业务方的反馈,导致用户验收测试的时候发现挺多不合乎预期的状况。从上图的数据中咱们能够失去一些要害信息: PT/LT只有39.2%,这就意味着两头有大量的等待时间。那咱们就能够具体分析每个等待时间该如何优化。构建上传和测试环境部署这两步都没有等待时间,而且%C/A是100%。因为这个案例中它们都是利用pipeline自动化实现的。因而,自动化能帮忙咱们进步%C/A和缩短等待时间。均匀%C/A是88.75%,意味着有能够改良的空间。那咱们就能够具体分析每个步骤中为什么达不到100%。通过剖析咱们发现,很多%C/A不能达到100%的起因是,这个步骤的人并没有频繁的向前一个步骤获取反馈来验证本人是否做对了。通过剖析咱们发现,很多LT长是因为,有一些审批流程必须等到领导审核能力往下持续走,而领导往往不能及时审批。还有一些LT长是因为没有可视化看板,不同步骤的人并不知道工作曾经ready了。在下面的例子中,破费在发明预期成绩上的工作工夫比例, 仅占总开销工夫的39.2%。这样的状况在惯例IT部门中,相似的占比数字相当广泛,甚至更低。 下面的例子依据价值流图最终剖析产出的报告有很多,这里就不具体开展说了。每个数字都能够钻研背地的起因和找到改良的计划。 有了价值流图之后,通常咱们能够提出来这3个问题: 为什么这些工作步骤的%C/A值低于100%?咱们如何才可能齐全杜绝谬误从一个步骤被传递到下一个步骤(并因返工而浪费时间和资源)?除了开发产品的工夫,具体有什么因素导致了lead time?咱们如何可能大幅升高队列和等待所损耗的工夫?3、咱们如何扭转工作实际,来升高每个步骤的解决的时长? 值流图的益处 价值流图的益处在于让参加的团队成员对整个流程有可视化的数据化的认知。并清晰的晓得该从哪个步骤动手开始改良。其次,过程的可视化出现,有助于聚焦到被发明的价值上,而不是被施行的动作上。员工们和经理们经常能很好地了解他/她们的日常工作(做什么),而漠视了预期成绩(为什么)。再次,价值流图有助于辨认和打消瓶颈,并防止局部优化的陷阱:即把工夫和精力破费在基本没有成果甚至带来负面成果的束缚打消上。最初,对价值流的理解,有助于实现DevOps的要害思维:构建一个顺畅、统一经各个步骤的价值流,使得咱们可能继续地、有节奏地、没有非必要的提早、并以最优的资源应用形式来交付成绩。基于Eliyahu Goldratt提出的束缚实践,任何零碎中,在任何一个工夫点上,有且仅有一个真正的瓶颈,这个瓶颈拖慢了工作,同时,破费在除了打消这个瓶 颈点之外的任何事件上的精力,都能够说是节约。总结要画出残缺的价值流图,肯定要去钻研我的项目中实在的实际是什么样子的,不能凭空想象,也不要去指望某些记录的文档信息,因为他们经常没人保护。 价值流图是帮忙咱们更好的构建DevOps的一种形式,要想做好DevOps只凭这一点是远远不够的。 如果大家对相干话题感兴趣,能够给我留言,咱们一起探讨更多可能性。 参考:《DevOps精要》

May 10, 2021 · 1 min · jiezi

关于devops:拒绝服务过载

简介对于“服务框架”,最难的一点是,如何给各个参数提供适当的默认值。特地是如果该参数会影响到性能或者服务的可用性。比方: Client-side Timeout服务端容许的最大连接数过载剖析(The anatomy of overload)在设计零碎时,咱们要将其设计为在遭逢过载状况之前被动扩大,来防止过载的产生。为了达到这一目标,咱们须要采取很多措施,包含: 主动扩大适当的加重负载监控机制继续测试通过对服务进行负载测试不难发现,低负载的服务器提早低于高负载的服务器。这是因为在该负载下,线程相互之间争用资源,导致须要进行频繁的上下文切换,垃圾回收和I/O争用也会变得更加显著。最终服务会达到一个拐点,在负载超过拐点后,服务的性能会开始疾速的降落。该察看背地的实践称为“Universal Scalability Law”,它衍生自Amdahl’s law,该实践指出,只管能够通过应用并行化来进步零碎的吞吐量,但零碎吞吐量最终会受制于串行化的吞吐量。(即受制于无奈并行化的工作) While a system’s throughput can be increased by using parallelization, it is ultimately limited by the throughput of the points of serialization (that is, by the tasks that can’t be parallelized)其次,吞吐量不仅受制于系统资源的限度,因为当零碎过载时,吞吐量通常会降落。尽管超载时计算机仍然能够失常工作,然而其会破费大量的工夫用于上下文切换,导致系统速度太慢从而不可用。在分布式系统中,客户端常常会设置有超时工夫。当服务器过载时,latency会超过超时工夫,申请会开始失败。下图显示了服务器的响应工夫,如何随着吞吐量的变大而变大。在上图中,当latency超过timeout时,申请将会大量失败。对与客户端来说,通过下图更能分明的反馈出服务的可用性,在这里应用median response time,其含意为50%的latency低于中值。如果将客户端的超时工夫设置为median response time,则一半申请将超时,因而可用性为50%。通过下图,能够将服务端的提早问题转换为客户端的可用性问题。形容可用性的一种更易懂的形式是辨别无效吞吐量和吞吐量。 吞吐量(goodput):是每秒发送到服务器的申请总数。无效吞吐量(throughput):是吞吐量的子集,它在承受解决的过程中没有产生谬误,而且具备足够低的提早(低于超时工夫),能够发送正确的相应给客户端。正反馈循环过载状况存在的问题在于它在反馈环路中会自我放大。如果客户端发来的申请超时,服务器在该申请上做的大量工作都将是有效工作。而零碎在过载状况下,最不应该做的就是有效工作。更蹩脚的是,客户端常常会对超时申请进行重试,这使得对系统的申请大量减少,使其远超过零碎所能接受的负载。而且,如果在面向服务的体系结构(SOA)中有足够深的调用图(即,A -> B -> C ...),并且如果每个层都执行了多次重试(侥幸的是,这一点在后面的文章中曾经提出了一些解决办法:https://segmentfault.com/a/11... ),则底层的过载将导致级联重试,从而会以指数模式放大申请的数量。当这些因素联合在一起时,过载会造成正反馈循环,从而导致系统不可复原。 避免做有效工作从外表上来看,load shedding很简略。只有当服务器靠近过载时,让它回绝多余的申请即可。load shedding的目标非常简单,避免客户端超时。通过这种办法,服务器能够为承受的申请放弃高可用性,而只会影响多余流量的可用性。通过缩小多余负载来管制提早,能够使零碎可用性更高。上图中总体可用百分比是在降落,这看起来比拟蹩脚,但要害是服务对决定承受的申请放弃了高可用。从而防止了服务器做有效工作。通过load shedding,即便总的吞吐量减少,服务器也能够维持肯定数量的无效吞吐量的解决。然而,load shedding并不是没有任何代价的,服务器最终还是会受限于Amdahl’s law,使无效吞吐量呈现降落。 测试

April 29, 2021 · 1 min · jiezi

关于devops:多主机的部署策略

最近在部署机器的时候发现有部署失败的状况,深入研究后发现是部署策略存在问题,导致部署不会开始。这里来钻研一下常见的部署策略。 部署限度部署速度设置同时可部署主机比例(legancy):通常咱们须要在部署速度与部署过程中服务的可用性方面进行衡量,部署速度一般来讲是将同一时间能够部署的主机数量设置为33.0%。同时部署的主机比例越高,部署实现的速度就会越快,然而对服务的需要超过其可用性的危险也就会越大。然而该形式未思考到部署的机器是否是衰弱的。机群“衰弱”设置“衰弱”主机的定义:以后没有正在部署的机器之前部署未失败的机器在失常运行中的机器,即能够失常接管流量的机器当对该局部内容进行设置时,须要保障机群的局部机器始终能够失常运行,如果有机器部署失败,将会进行进一步部署。“衰弱”主机的比例是咱们在这里须要思考的参数,其值越低部署的速度就越快,对服务的需要超过其可用性的危险也就越大。在这里咱们能够思考以下参数来对其进行设置。 衰弱主机百分比:通常状况下,将该值设置为66%,这意味着有66%的hosts将始终保持衰弱的状态。这里须要思考到的一个非凡状况是,如果只有两台主机,那么在该限度下将不会进行部署。因而咱们须要引入新的参数。容许回退有效的衰弱主机百分比:该参数能够设置为true或者false,在设置为true的状况下,如果遇到下面提到的非凡状况,即衰弱主机百分比设置为66%,而只有两台主机的时候,会主动调整比例为(2-1)/2 = 50%,以便能够至多部署一台。同样,对于只有一台主机的状况下,如果该参数为true,则会将66%调整为(1-1)/1 = 0%,即可容许部署进行。best practice衰弱主机百分比: 66%容许回退有效的衰弱主机百分比: true 服务健康检查服务上线应该保障十拿九稳,因而咱们应该在部署过程中对服务再次进行测试。通常来说,这包含健全性测试与验证测试。 健全性测试:该步骤通过运行测试来确定所在主机上运行的软件是否良好。它会在接管流量前运行。 验证测试:该步骤用来测试要害性能是否失常运行,它可能会在服务开始接管流量后进行,因而应用该测试须要分外小心。 主动回滚:关上该性能,能够为该部署增加监控和警报,如果在部署后一段时间,某些监控项偏离咱们设定的范畴,咱们能够主动回滚到上个版本。 主机抉择对于部署的机器咱们也能够进行更加细粒度的抉择,比方应该同时部署某个可用区中的机器,还是按比例部署所有可用区中的机器等。 跨数据中心部署:关上该设置,能够均衡部署咱们所有可用区中的机器,即,如果咱们有30台主机均匀散布在三个可用区上,并且曾经将最大部署比例设置为30%,那么将会抉择九台机器,每个可用区中抉择三台。 通过调整适合的部署策略,能够在最大水平上保障咱们服务的可用性。

April 28, 2021 · 1 min · jiezi

关于devops:ELK-教程-高效发现分析和可视化你的数据

【注】本文译自:https://www.edureka.co/blog/e... 随着越来越多的 IT 基础设施转身云计算,对公共云平安工具和日志剖析平台的需要也在迅速减少。不论组织的规模有多大,每天都会生成大量的数据。这些数据中有相当一部分是由公司的 Web 服务器日志组成的。日志是最重要的信息起源之一, 但往往被忽视。每个日志文件都蕴含一些贵重的信息,这些信息大多是非结构化的,没有任何意义。如果不对此日志数据进行详尽的剖析,那么企业可能会漠视其四周的机会和威逼。这是日志剖析工具十分有用的中央。ELK Stack 或 Elastic Stack 是残缺的日志剖析解决方案,它有助于深刻搜寻、剖析和可视化不同机器生成的日志。通过本教程,我将为您提供相干见解。 首先,让咱们列出要探讨的主题: 什么是 ELK Stack?ELK Stack 架构ELK Stack 装置Elasticsearch 教程Logstash 教程Kibana 教程 本教程将帮忙您一起了解 Elasticsearch、Logstash 和 Kibana 的基础知识,并帮忙您在 ELK Stack 中打下松软的根底。 首先让咱们来理解什么是 ELK Stack。 什么是 ELK Stack? 家喻户晓的 ELK Stack 最近被更名为 Elastic Stack。它是三个开源工具的弱小汇合:Elasticsearch、Logstash 和 Kibana。 这三种不同的产品最常一起用于不同 IT 环境中的日志剖析。应用 ELK Stack,您能够执行集中式日志记录,这有助于辨认 Web 服务器或应用程序的问题。它使您能够在一个中央搜寻所有日志,并通过在特定工夫范畴内关联多个服务器的日志来辨认跨多个服务器的问题。 当初让咱们具体探讨这些工具。 LogstashLogstash 是数据收集管道工具。它是 ELK Stack 的第一个组件,它收集数据输出并将其输出到 Elasticsearch。它能够一次从不同起源收集各种类型的数据,并立刻提供以备未来应用。 ElasticsearchElasticsearch 是基于 Lucene 搜索引擎的 NoSQL 数据库,并应用 RESTful API 构建。它是一个高度灵便的分布式搜寻和剖析引擎。此外,它通过程度可伸缩性提供了简略的部署、最大的可靠性和易于治理的性能。它提供高级查问以执行详细分析,并集中存储所有数据以疾速搜寻文档。 KibanaKibana 是一种数据可视化工具。它用于可视化 Elasticsearch 文档,并帮忙开发人员立刻对其进行深刻理解。Kibana 仪表板提供了各种交互式图表、天文空间数据、工夫线和图表,以可视化应用 Elasticsearch 实现的简单查问。应用 Kibana,您能够依据本人的特定需要创立和保留自定义图形。 下一部分将探讨 ELK Stack 架构以及其中的数据流向。 ...

April 28, 2021 · 3 min · jiezi

关于devops:超时与重试

WHY当一个service去调用另一个service时,就有可能会产生故障。这些故障可能是由与各种起因所引起的,比方: 服务器端客户端网络负载均衡器软件操作系统设计零碎的目标是缩小产生故障的可能性,但咱们无奈构建永不中断的零碎。因而咱们须要做的是进一步设计咱们的零碎,以“容忍”故障,并防止将一小部分故障放大为一次系统性的故障。 WHAT超时(timeouts)许多类型的失败体现为申请破费的工夫比平时更长,并且可能永远无奈实现。如果客户端期待响应的工夫比个别状况下长得多,则在客户端期待时,会将资源持有更多工夫。这会导致内存,线程,连贯,长期端口或其余任何无限资源的耗尽。为了防止这种状况,客户端设置了timeouts,即客户端违心期待申请实现的最长工夫。 重试(retry)通常,将失败的申请再次进行尝试会胜利。产生这种状况是因为咱们构建的零碎通常不会作为一个整体而失败:相同,它们会产生局部故障(肯定比例的申请胜利)或短暂故障(申请在短时间内失败)。重试容许客户端通过再次发送雷同的申请来防止“随机”产生的局部故障或短暂故障。被重试的服务肯定须要是幂等的。 HOW如何设置超时工夫设置超时工夫是一个须要衡量的事件。如果咱们将超时工夫设置的过大,那么就会失去设置它的意义,因为client在期待超时时仍会耗费资源。而如果咱们设置的过小,会导致重试次数过多,减少后端流量,进而会减少服务的提早,而该提早的减少,又会进一步导致更多的重试,进而有可能造成齐全的中断。抉择一个好的超时工夫通常须要咱们观测RPC申请延时,一般来说会设置为申请延时的p99。这样的设置会有可能在网络中产生两个雷同的申请,期待较早返回的申请即可。但在某些状况下须要咱们更加认真的进行剖析,比方: 某些地区的客户端总是产生比拟大的提早。比方可能是因为咱们的客户遍布寰球,而该地区间隔服务器很远等起因。在这种状况下,咱们要思考的正当的最坏状况下的网络提早。此办法也不适用于latency相差不大的状况下,比方p50十分靠近p99。在这些状况下,能够增加一些buffer。如何设置重试次数以及重试间隔时间始终记住的一点是:Retries are “selfish.” 重试的危险重试会加大间接上游的负载。假如 A 服务调用 B 服务,重试次数设置为 r(包含首次申请),当 B 高负载时很可能调用不胜利,这时 A 调用失败重试 B ,B 服务的被调用量疾速增大,最坏状况下可能放大到 r 倍,不仅不能申请胜利,还可能导致 B 的负载持续升高,甚至间接打挂。更可怕的是,重试还会存在链路放大的效应。假如当初场景是 Backend A 调用 Backend B,Backend B 调用 DB Frontend,均设置重试次数为 3 。如果 Backend B 调用 DB Frontend,申请 3 次都失败了,这时 Backend B 会给 Backend A 返回失败。然而 Backend A 也有重试的逻辑,Backend A 重试 Backend B 三次,每一次 Backend B 都会申请 DB Frontend 3 次,这样算起来,DB Frontend 就会被申请了 9 次,理论是指数级扩充。假如失常访问量是 n,链路一共有 m 层,每层重试次数为 r,则最初一层受到的访问量最大,为 n * r ^ (m - 1) 。这种指数放大的效应很可怕,可能导致链路上多层都被打挂,整个零碎雪崩。重试治理动静配置 如何让业务方简略接入是首先要解决的问题。如果还是一般组件库的形式,仍旧免不了要大量入侵用户代码,且很难动静调整。字节跳动应用了middleware(中间件)模式,将业务代码和非业务代码进行理解耦。他们定义了一个middleware并在外部实现了对RPC的反复调用,把反复的配置信息用分布式存储核心进行存储,这样middleware能够读取配置核心的配置并进行重试,对用户来说不须要批改调用RPC的代码,而只须要在服务中引入一个全局的middleware即可。 如上面的整体架构图所示,他们专门提供了配置的网页和后盾,使用户可能在专门进行服务治理的页面很不便的对RPC进行配置批改并主动失效,外部的实现逻辑对用户通明,对业务代码无入侵。 配置的纬度依照了字节的RPC调用特点,选定[调用方服务,调用房方集群,被调用方服务,被调用方办法]为一个元组,依照元组进行配置。Middleware中封装了读取配置的办法,在RPC调用的时候会主动读取并失效。 这种middleware形式可能让业务方很容易接入,一次接入当前就具备动静配置的能力,能够很不便地调整或者敞开重试配置。退却策略 ...

April 26, 2021 · 1 min · jiezi

关于devops:Artifactory使用命令行构建集成

应用Artifactory作为制品库,不仅仅能够治理制品自身,还能够集成CI收集构建的BuildInfo。对于Jenkins,TFS来说,Artifactory专门开发了插件反对。然而CI流水线工具的品种有很多,并不是每一种咱们都可能去开发插件去反对,对于这种状况咱们就须要应用一种通用兼容的办法来去集成,那就是命令行。JFrog Cli简介JFrog专门开发了一个命令行客户端工具JfrogCli,该工具不仅能够反对简略的上传下载文件,还能够集成构建,收集buildinfo。要应用首先下载JFrog Cli命令行工具,反对Linux/Windows/Mac零碎,并且JFrogCli是基于Go语言开发的,凋谢了源代码,对于非官方反对的零碎能够自行下载源码编译。客户端下载地址:https://jfrog.com/getcli/源码地址:https://github.com/jfrog/jfro...下载实现命令行之后,搁置在零碎$PATH下测试执行,胜利后返回后果。jfrog --verison JFrog Cli配置 配置Cli与Artifactory链接jfrog rt c 校验链接是否胜利jfrog rt ping构建Maven我的项目上面就给大家展现一个maven我的项目的案例:我的项目源码地址https://github.com/jfrog/proj...配置mvn仓库下载和上传 配置环境变量指定Maven_Homeexport M2_HOME=/opt/apache-maven-3.8.1/应用Cli客户端执行mvn构建,并指定Build信息jfrog rt mvn clean install --build-name=jfrog-mvn-test --build-number=1 上传Build信息 收集环境变量jfrog rt build-collect-env jfrog-mvn-test 1 上传BuildInfojfrog rt build-publish jfrog-mvn-test 1构建后果被上传到了Artifactory中能够看到制品和依赖 收集BuildInfo的作用收集制品构建依赖收集制品构建环境信息制品构建组件平安扫描制品升级感兴趣的还能够尝试其余各种语言的我的项目进行构建。具体步骤能够参考咱们官网wiki。https://www.jfrog.com/conflue...

April 23, 2021 · 1 min · jiezi

关于devops:Jenkins教程使用Jenkins进行持续集成

【注】本文译自:https://www.edureka.co/blog/j... 本文将重点介绍 Jenkins 架构和 Jenkins 构建管道,并向您展现如何在 Jenkins 中创立一个构建。 当初是理解 Jenkins 架构的正确机会。 Jenkins 架构 让咱们批改一下我在上一个博客中向您解释的独立 Jenkins 架构,下图描述了雷同的架构。 单台 Jenkins 服务器不足以满足某些要求,例如: 有时您可能须要几个不同的环境来测试您的构建。单个 Jenkins 服务器无奈实现此操作。如果定期构建更大、更重的我的项目,则单个 Jenkins 服务器将无奈简略地解决整个负载。 为了满足上述需要,引入了 Jenkins 分布式架构。 Jenkins 分布式架构 Jenkins应用主从架构治理分布式构建。在这种架构中,主站和从站通过 TCP / IP 协定进行通信。 Jenkins 主节点 您的次要 Jenkins 服务器是主节点。主节点的工作是解决: 调度构建作业。将构建分派给理论执行的从节点。监督从节点(可能依据须要使它们联机和脱机)。记录并显示构建后果。Jenkins 的主节点也能够间接执行构建作业。 Jenkins 从节点 从节点是在近程计算机上运行的 Java 可执行文件。以下是 Jenkins 从节点的特点: 接管来自 Jenkins 主接点的申请。从节点能够在各种操作系统上运行。从节点的工作就是依照命令执行,包含执行主节点调配的构建作业。您能够将我的项目配置为始终在特定的从节点或特定类型的从节点上运行,或者仅让 Jenkins 抉择下一个可用的从节点。 下图是不言自明的。它由一个 Jenkins 主节点治理三个 Jenkins 从节点。 当初,让咱们看一个示例,其中 Jenkins 用于在不同的环境中进行测试,例如:Ubuntu、MAC、Windows等。 如下图所示: 上图中执行以下性能:Jenkins 会定期检查 Git 存储库中是否有任何源代码更改。每个构建都须要不同的测试环境,这对于单个Jenkins服务器是不可能的。为了在不同的环境中执行测试,Jenkins 应用了各种从节点,如图所示。Jenkins 主节点要求这些从节点执行测试并生成测试报告。 ...

April 11, 2021 · 1 min · jiezi

关于devops:什么是-Jenkins-运用Jenkins持续集成

【注】本文译自:https://www.edureka.co/blog/w... 继续集成是 DevOps 最重要的局部,用于集成各个 DevOps 阶段。Jenkins 是最驰名的继续集成工具,我晓得你很好奇 Jenkins 受欢迎的起因以及 Jenkins 是否容易学习。我确信浏览完本文后,您的所有问题都会失去解答。 让咱们用简要概括什么是 Jenkins。 什么是 Jenkins 以及为什么要应用它? Jenkins 是一个用 Java 编写的开源自动化工具,带有用于继续集成的插件。Jenkins 用于继续构建和测试您的软件我的项目,从而使开发人员更容易将更改集成到我的项目中,并使用户更容易取得新的构建。它还容许您通过与大量测试和部署技术集成来继续交付软件。 借助 Jenkins,组织能够通过自动化来减速软件开发过程。Jenkins 集成了各种开发生命周期过程,包含构建、文档、测试、打包、模仿、部署、动态剖析等等。 Jenkins 借助插件实现了继续集成。插件容许集成各种 DevOps 阶段。如果要集成特定工具,则须要装置该工具的插件。例如 Git、Maven 2 我的项目、Amazon EC2、HTML 发布者等。 下图描述了 Jenkins 正在集成各个 DevOps 阶段: Jenkins 的劣势包含:是一个具备社区大力支持的开源工具。易于装置。领有 1000 多个插件,可简化您的工作。如果不存在插件,则可通过编码实现并与社区共享。它是收费的。它是用 Java 构建的,因而能够移植到所有次要平台。 Jenkins 的某些方面将其与其余继续集成工具辨别开来。让咱们看看这些要点。 Jenkins 的个性 以下是无关Jenkins的一些事实,这些事实使它比其余的继续集成工具更好: 利用:Jenkins 利用十分宽泛,在寰球范畴内有超过 147,000 个沉闷装置和超过 100 万用户。插件:Jenkins 与1000 多个插件互连,从而使其能够与大多数开发、测试和部署工具集成。 从以上几点能够看出,Jenkins 在寰球范畴内有很高的需要。在咱们深入研究 Jenkins 之前,先理解什么是继续集成以及它的重要性。 什么是继续集成? 继续集成是一种开发实际,在这种实际中,要求开发人员每天屡次或更频繁地对共享存储库中的源代码提交更改。而后构建存储库中进行的每个提交。这使团队能够及早发现问题。除此之外,依据继续集成工具的不同,还有其余一些性能,例如在测试服务器上部署构建应用程序,为相干团队提供构建和测试后果等。 让咱们通过用例理解它的重要性。 继续集成示例:诺基亚 我敢肯定,您毕生中的某些时候都应用过诺基亚手机。在诺基亚的一个软件产品开发我的项目中,有一个名为每晚构建(Nightly builds)的过程。每晚构建能够被认为是继续集成的前身。这意味着每天晚上,自动化零碎都会拉一整天增加到共享存储库中的代码并构建该代码。这个想法与继续集成十分类似,然而因为在夜间构建的代码很大,因而查找和修复谬误的确很麻烦。因而,诺基亚采纳了继续集成(CI)。 后果,构建了对存储库中的源代码的所有提交。 如果构建结果表明代码中存在谬误,则开发人员仅须要查看该特定提交。 这大大减少了公布新软件所需的工夫。 当初是理解 Jenkins 如何实现继续集成的正确机会。 ...

April 8, 2021 · 1 min · jiezi

关于devops:2021-年-DevOps-的八大趋势-IDCF

本文先看看他人的预测,最初我也凭借本人在 DevOps 畛域这几年的教训和认知,大胆预测DevOps 在2021年的倒退与变动。 他人的预测本文翻译自 Andreja Velimirovic 的 《Top 8 DevOps Trends for 2021》 一文,原文地址[1]。DevOps 是软件无效交付的一个当先模型,而且此畛域没有停滞的迹象。DevOps 社区始终在搜查优化开发效率、进步生产力的形式,因而思维和流程的转变是以 DevOps 为核心的软件开发模式中的外围局部。 此文章会就 2021 年 DevOps 的八大趋势做一个解释。 持续浏览,理解2021年 DevOps 的冀望,并理解你的团队须要做什么来放弃竞争力。 一、DevOps值得关注的趋势1.1 基础设施自动化(IA)工具的成熟基础设施自动化工具可能使团队在 on-premise 和云环境中设计和自动化交付服务。在 2021 年,DevOps 团队将应用 IA 以更高的可靠性来大规模施行自动化 IT 基础设施的交付、配置和治理。 IA 工具可能给 DevOps 团队提供泛滥的收益: 多云和混合云基础设施的编排。不可变和可编程基础设施的反对。自服务、按需所需环境的创立。高效的资源配置。试验的简略性。咱们将在将来看到 IA 工具和其余流水线组件的更多集成。通过将 CI/CD 概念利用于 IT 基础设施,团队将能享受到更多的敏捷性。 查看继续集成、继续部署和继续交付之间的区别[2],三种实际使 DevOps 团队疾速、准确的工作。2021年的冀望:企业将开始用企业级的 IA 工具取代自定义的设置。通过利用 IA 工具来自动化软件的部署和配置,企业将取得: 更快的开发。可反复、统一的基础设施。因为手动工作缩小使老本升高。因为跨所有物理和虚构基础设施的可靠性设置,更容易实现合规。预计间断配置自动化(CCA) 的工具也会减少。这些工具提供了以代码模式治理和交付配置更改的能力。CCA 工具的范畴将会持续扩大至网络、容器、合规及平安领域。 查看裸金属[3]云服务器是如何帮忙施行基础设施自动化治理流程的。1.2  应用程序公布编排(ARO)工具的应用ARO 工具将流水线、环境治理和版本编排联合起来。这些工具可能带来以下益处: 更多的灵活性:团队能更快、更牢靠的交付新利用、应答变更和修复缺点。更高的生产力:更少的手动工作能容许成员更关注于高价值工作。更好的可视性:在资源调配过程中,瓶颈和期待状态变得可见。ARO 工具将进一步提高产品公布的品质和速度。公司将利用多种形式、DevOps 流水线[4]、流程及工具,在多团队之间进行版本公布流动。 2021 年冀望什么:ARO 工具将变得更加广泛。新变更的疾速交付将容许对市场需求的疾速扭转做出应答。 ...

April 1, 2021 · 2 min · jiezi

关于devops:对象存储服务Minio

Mino[TOC] 对象存储服务(Object Storage Service,OSS)是一种海量、平安、低成本、高牢靠的云存储服务,适宜寄存任意类型的文件。容量和解决能力弹性扩大,多种存储类型供选择,全面优化存储老本。 对象存储服务在我的项目开发过程中,咱们会产生大量的对象数据,包含:日志文件,数据库脚本文件、安装包,容器镜像,图像、视频等等,咱们不仅仅是须要有一个集中的中央来存储,还须要能基于 Web 的形式来拜访它们,以往咱们有以下几种办法来解决: 阿里云、Azure 等云服务商提供的SaaS 级别的 OSS 服务本人搭建 NAS 网络存储通过 Samba 服务来拜访本人搭建 FTP 服务器来存储 本篇文章次要介绍下其中的Minio计划 MinioMinio是GlusterFS创始人之一Anand Babu Periasamy公布新的开源我的项目。Minio兼容Amason的S3分布式对象存储我的项目,采纳Golang实现,客户端反对Java,Python,Javacript, Golang语言。 Minio是建设在云原生的根底上;有分布式和共享存储等性能;旨在多租户环境中以可继续的形式进行扩大的对象存储服务。它最适宜存储非结构化数据,如:照片、视频、日志文件、容器/虚拟机/映像等,单次存储对象的大小最大可达5TB 参考https://min.io/http://www.minio.org.cn/minio/minio-service: Collection of MinIO server scripts for upstart, systemd, sysvinit, launchd. (github.com)Minio 架构 右边是 MINIO 集群的示意图,整个集群是由多个角色完全相同的节点所组成的。因为没有非凡的节点,所以任何节点宕机都不会影响整个集群节点之间的通信。通过 rest 跟 RPC 去通信的,次要是实现分布式的锁跟文件的一些操作 左边这张图是单个节点的示意图,每个节点都独自对外提供兼容 S3 的服务 为什么要用 Minio1、Minio 有良好的存储机制2、Minio 有很好纠删码的算法与擦除编码算法3、领有RS code 编码数据复原原理4、公司做强做大时,数据的领有重要性,对数据治理与大数据分析做筹备。5、搭建本人的一套文件系统服务,对文件数据进行平安爱护。6、领有本人的平台,不限于其余方限度。存储机制Minio应用纠删码erasure code和校验和checksum来爱护数据免受硬件故障和无声数据损坏。 即使失落一半数量(N/2)的硬盘,依然能够复原数据。纠删码纠删码是一种复原失落和损坏数据的数学算法,目前,纠删码技术在分布式存储系统中的利用次要有三类,阵列纠删码(Array Code: RAID5、RAID6 等)、RS(Reed-Solomon)里德-所罗门类纠删码和 LDPC(LowDensity Parity Check Code)低密度奇偶校验纠删码。Erasure Code 是一种编码技术,它能够将 n 份原始数据,减少 m 份数据,并能通过 n+m 份中的任意 n 份数据,还原为原始数据。即如果有任意小于等于 m 份的数据生效,依然能通过剩下的数据还原进去MinIO概念如下图,每一行是一个机器节点,这里有32个集群,每个节点里有一个小方块,咱们称之为Drive,Drive可简略地了解为磁盘。一个节点有32个Drive,相当于32个磁盘。 ...

March 27, 2021 · 2 min · jiezi

关于5g:DevOps助力5G-IDCF

敬爱的小伙伴,你换5G手机了吗?咱们说,4G扭转生存,5G扭转社会。你晓得为什么5G会扭转社会吗?让咱们先来理解下5G业务场景。 从1G到4G,挪动通信的外围是人与人之间的通信,然而5G却不仅仅是人与人的通信,而是人与物、物与物之间的通信。国际标准化组织3GPP定义了5G的三大场景,如下图。 其中,eMBB指大流量挪动宽带业务。mMTC指大规模IoT物联网业务,URLLC指如无人驾驶、工业自动化等低时延、高牢靠连贯的业务。如此简单的新业务,势必要求5G的关键技术与4G相比有着天壤之别,分布式云、网络切片、边缘计算、NFV、SDN等技术接踵而来。5G利用的简单、网络部署的扭转、新技术的迭代、越发简单的运维,这些对运营商来说都是微小挑战。 DevOps是5G落地的必由之路。麻利开发突破了业务和开发的部门墙,DevOps突破了开发与运维的部门墙。而狭义的DevOps是一种文化,一种端到端的自动化服务。 传统通信网络,软硬件一体化,关闭求稳,很多业务开发与撑持都须要硬件设施商的反对。当初5G网络的特点是:软硬解耦、硬件X86云、,软件分层、切片。这一技术特点为软件开发商提供了大量进入的机会。 5G业务品种繁多,变化多端,目前大多数的设施商,开发商都有本人的DevOps流水线,麻利开发,然而却不能间接部署到运营商现网。如果开发商和运营商之间的交付鸿沟买通,对通信行业的疾速倒退十分无利。 对DevOps而言,只有是软件,是制品包,不论什么业务,DevOps生产线都能麻利解决。能够预感,5G的接入网,核心网畛域,都是能够发展DevOps。当然,咱们也能看到一些难度。比方,在CT生态环境中,运营商不可能让设施商把源代码拿过去集成。那么是不是能够用组件集成或者服务集成呢?这些都是能够钻研的。 从运维角度看,传统的2G/3G/4G运维平台,都无奈撑持5G网络资源的集中统一的配置管理和运维;5G网络软件解耦,粒度变小,继续公布也是刚需;同时,对于垂直利用的”按需定制”,很难做到智能运维,这些网络性能管制,治理运维,当前都会有DevOps来驱动参加。置信目前的运营商曾经在钻研了。 不难看出,CT逐步向IT聚拢,5G的很多痛点必须有DevOps帮助。咱们也能够瞻望下将来,3GPP规范是不是也能够麻利化?运维是不是一个大中台流水线能够搞定?很多入网许可的流程是不是也能够自动化实现?让咱们期待! 起源:IDCF社区 作者:FDCC认证学员 赵福辰关注公众号回复“FDCC”可收费报名认证

March 17, 2021 · 1 min · jiezi

关于devops:原创笔记CICD系列之三goharbor安装

CICD系列之三:goharbor装置筹备主机:10.0.0.14 将Harbor装置在linux上。在装置Harbor之前,必须确保机器上曾经装置了docker 17.06.0-ce+和docker-compose 1.18.0+。 1. 降级docker(按需)wget https://download.docker.com/l...yum -y install docker-ce-17.06.2.ce-1.el7.centos.x86_64.rpm 2. 下载在线安装包wget https://github.com/goharbor/h... 3. 配置SSL证书创立证书寄存目录mkdir -p /data/cert && cd /data/cert 生成根证书私钥(无加密)openssl genrsa -out ca.key 2048 openssl req -x509 -new -nodes -key ca.key -days 10000 -out ca.crt -subj "/CN=Harbor-sz" 生成服务器端私钥和CSR签名申请openssl req -newkey rsa:4096 -nodes -sha256 -keyout server.key -out server.csr 签发服务器证书echo subjectAltName = IP:10.0.0.14 > extfile.cnfopenssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -extfile extfile.cnf -out server.crt ...

March 13, 2021 · 1 min · jiezi

关于devops:成为你向往的那只独角兽-独角兽项目出版在即

以下文章来源于DevOpsClub ,作者张乐 写下本文题目的时候,我才意识到曾经良久没有更新微信公众号了(尽管过来一年我做过很多在线直播和大会演讲)。但明天动笔写下这篇文章却是一个很好的机会,一方面春天曾经到来,万物复苏、生机勃勃;更重要的是,有一件让我分外冲动的事件:耗时一年多工夫翻译、校对、制作的《独角兽我的项目: 数字化转型时代的开发传奇》终于要正式出版了! 兴许你曾经据说过这本书了,没错,这本书去年在国外十分火。它有很多光环:在寰球销售500,000册的超级畅销书《凤凰我的项目》的续作和姊妹篇 明天我要认真的做下这本书的举荐,不仅是我和孙振鹏、许峰两位好友与人民邮电出版社图灵公司单干翻译了这本书,更是粗浅感触到书中的故事和蕴含的哲理,以及作者提炼出的全新理念对当今数字化时代泛滥企业谋求的生存和翻新倒退的领导价值。正如耐克寰球技术副总裁Courtney Kissler所说:“每一家正在经验数字化转型的公司都应该把这本书作为所有领导者的必读书目。” 这本书的前世今生本书的前作,也就是畅销书《凤凰我的项目:一个IT运维的传奇故事》的英文版是2013年出版的,距今曾经有近8年工夫了。《凤凰我的项目》之所以滞销,很大水平上是因为它通过一个叙事体的传奇故事传播出的IT治理思维精华。书中讲述了一位IT经理临危受命,在将来董事的帮忙和本人“三步工作法”实践的撑持下,胜利解救了一家悠久历史的公司。故事揭示了治理古代IT组织与治理传统制造业的共通之处,让读者不仅能对如何治理IT组织心领神会,并以齐全不同于以往的视角来对待本人的工作环境,从而思考精益、束缚实践、DevOps、交付流水线等等办法和实际的利用。加之作者提炼出精辟的“三步工作法”、“四种工作类型”,让这本书成为了很多人DevOps实践者的入门必选书籍。 但世界还在继续疾速向前演进,几年工夫过来了,业界能够说产生了天翻地覆的变动,业务模式的疾速翻新、技术和各类办法实际的蓬勃发展,数字化颠覆的案例越来越多…《凤凰我的项目》也须要与时俱进了。 于是,姊妹篇《独角兽我的项目》终于到来,本书的呈现能够说是恰逢其时,它讲述了一个与凤凰我的项目同时进行的以DevOps为外围实际的数字化转型的案例故事。正如作者Gene Kim所说:“这是一个对于叛变的开发者和业务领导者一起工作,他们争分夺秒地翻新、想方法生存,并在一个前所未有的不确定性和充斥时机的时代蓬勃发展的故事。” 故事中的关键人物玛克辛是一位才华横溢的首席开发人员和架构师,她被当作是一次宕机事变的责任人,并被踢出了团队(听起来是不是很耳熟?相似寻找替罪羊故事时常在咱们身边产生)。但与其余悲情故事不同的是,玛克辛与公司内的一些异见者组成了一支“反抗军”团队,独特面对他们过来积攒的各种组织、文化和技术问题,以及冲突变动的弱小的公司旧秩序,并使用“五大理念”打造出了踊跃且长久的业务、技术和文化改革,让工程效率思维深入人心,最终使公司解脱了窘境,取得了像独角兽公司那样的精英研发效力,翻新业务取得了极大胜利,本人也成为了公司历史上的首位“卓越工程师”。 这个故事对于在中大型企业工作的人们并不生疏。对于许多试图转型为数字化精英企业的组织来说,这些挑战是很常见的。“五大理念”中所形容的文化和组织准则是实现可继续业务产出的根底,并且曾经被社区提炼和驳回为DevOps和数字化转型的外围价值观和准则。 这本书为什么值得举荐这本书证实了DevOps静止的重要性,因为它是一种更好的工作形式,能够更快、更平安、更高兴地交付更优的价值。本书描述了在扩大DevOps并晋升研发人员工作效率时,所需的、但不可见构造和架构。本书提出的“五大理念”独特发明了引发业务翻新的适合环境,它使组织可能保留维持盈利业务所需的构造,同时改良和突破妨碍增长和翻新的构造。 一、本书精华:五大理念继在《凤凰我的项目》中提出的“三步工作法”、“四种工作类型”根底之上,本书提出了一系列新的价值观和准则,被称为”五大理念”,以应答影响当今工程和业务最重要的 IT 挑战: 第一理念:局部性和简略性;第二理念:专一、流动和高兴;第三理念:改善日常工作;第四理念:心理平安;第五理念:以客户为核心。第一理念:局部性和简略性 局部性指的是开发团队能在多大程度上在一个地位(而不是许多中央)进行所需代码更改,而不会影响其余团队。如果一个团队须要安顿部署打算,并且须要其余很多团队与他们一起制订打算,那么到头来什么都做不成。此外,如果负责交付繁多性能的团队必须与其余两支或许多开发团队协调,那么这只会给所有这些团队带来提早和挑战。这就是局部性的概念。 局部性须要简略性:简略性是指,咱们能够在多大程度上真正使应用程序彼此解耦,并齐全拆散它们。关注点拆散(Separation Of Concerns)、繁多责任准则(Single Responsibility Principle)、内聚性/可重用性(Cohesiveness/Reusability)都合乎这一理念。 第一理念实用于架构模式,并且与”改善日常工作”的第三理念相干,因为要实现第一理念,咱们须要腾出工夫进行日常改良,并优先思考缩小技术债权。 第二理念:专一、流动和高兴 当开发人员可能专一于以最小的依赖关系、提早和阻碍来编写代码时,这就会发明价值流,从而带来高兴。当他们全神贯注工作时会真正领会到乐趣,遗记工夫,甚至达到忘我的境界。这就是开发人员的工作意义所在。比方通过开发自服务,让开发人员能够按需、间接和疾速获取测试反馈,这样就能够晋升开发人员生产力。第三理念:改善日常工作 改善日常工作,从而解决技术债权和架构问题。FAANG(Facebook、Amazon、Apple、Netflix、Google)等精英组织之所以会胜利,是因为他们都无意识地决定还清技术债权。他们全都竭尽所能,以确保开发人员的日常工作可能顺利完成,并尽可能减少烦扰和妨碍。乏味的是,所有这些公司的首席执行官都是技术领导者。而有一些公司(比方诺基亚就是一个很好的例子)过后并没有优先解决其技术债权,或推动其技术和架构的现代化。须要留神的是,精英效力并不是收费得来的,而是须要进行必要的投资。很多胜利的公司让3-5%的开发者专一于晋升开发生产力,比方Google有超过1500人、微软有超过3000人专一于这类的事件。第四理念:心理平安 咱们从《寰球DevOps现状调查报告》以及谷歌的多份重要钻研中能够得悉,心理平安是高效能团队的要害预测指标之一。比方谷歌就确立了一种制度,通知团队成员在多大程度上能够平安地探讨问题、说出本人的想法而不用放心受到谴责或被讥笑、指摘。DevOps实际中常常会提到的”免责事变回顾(Blameless Post-Mortems)”就是这一理念的代表。 第五理念:以客户为核心 要关注外围(Core)和非核心(Context)之间的差别。外围(Core)发明长久的业务劣势,而非核心(Context)则是其余所有。外围是客户违心领取费用的组织外围能力,他们不关怀其余非核心业务。例如,咱们喜爱人力资源零碎、工资单和反对员工的零碎,然而客户不违心为世界一流的工资单零碎买单。这些零碎尽管也很重要,但并不能发明竞争劣势。在咱们为外围性能和应用程序提供资金时,咱们须要确保外围不会被非核心扼杀。咱们还要从数据失去洞察,关注客户须要什么,以及如何满足。不要让某个职能仓筒经理的指标高于业务指标。二、让人共情的案例故事咱们常常心愿去寻找一些有价值的案例,来帮忙咱们了解麻利、DevOps以及数字化转型中的那些治理、技术实际和新范式。咱们能够去加入技术大会或听一些演讲,但因为时长和篇幅所限,大多案例只有2-3分钟的工夫简略给听众交代下背景。而实际上,各个组织背景和环境差别微小,如果不能粗浅领会到改革所处的上下文,可能就很难了解所采取的改良计划的思路和施行过程。每个组织的上下文都是独特的,DevOps畛域并没有One Size Fits All的计划,也没有放之四海而皆准的规范办法,深刻了解一个案例首先要把背景搞清楚。 本书形容了与《凤凰我的项目》产生在同一期间的精彩故事的另一个版本,其中有许多雷同的角色。但《独角兽我的项目》的故事是从开发者(而不是从IT和基础设施运维)的角度来写的,没有过分强调对运维的关注,因为依据企业的价值流,业务需要通常是从开发开始的。通过这一点,咱们对立了从凤凰我的项目引入的DevOps愿景,同时也带来了以客户为核心的数字化转型的根底。 书中有太多实在(兴许看起来过于实在)的案例场景,包含零碎宕机、寻找背锅侠、组织结构调整、我的项目紧急公布、遇到重大事故后决定解冻上线、厚重的部门墙和简单的沟通协调、大型零碎无奈编译构建、找不到可用的测试环境、开发和测试是间隔很远的不同团队、大量工单流转效率低下、大促期间数据系统解体不可用、公司估算削减和强制裁员、工程能力建设的崎岖历程…好在,团队与领导层最终从新调整了策略,在一家传统的、悠久历史的企业中展现出了可能是独角兽公司才具备的弱小创新力、精英效力和企业生机,最终发明出了一个数字化时代的传奇。 书中的故事内容尽管是虚构的,然而很多素材都来自于行业中的实在案例,比方寰球DevOps企业社区(DevOps Enterprise Summit)中多年来积攒的案例故事,作者还奇妙地把这些素材有机地组织和整合在了一起,让读者齐全沉迷在这个既实在又”残缺”的、与时俱进的精彩故事中,并与书中人物和团队产生共情,从而结构出一种让所有变得更好的动机,驱动着咱们做出一些合乎这个时代定位的、对企业和本人更有意义的事件。 三、宽泛的指标读者群本书的受众十分宽泛,包含CXO、企业各级领导者、麻利/精益/DevOps爱好者和实践者、技术架构师、技术领导者、业务畛域或产品专家,还有宽广的一线开发/测试/运维/平安工程师。 本书心愿能激发读者们一起思考,促成一线工程师与业务/技术领导者交换,独特了解数字化改革的紧迫性,并作为一个作证,证实他们在日常工作中所须要取得的各种资源和数据,这些能更好地促成交付业务价值。当然,也心愿技术领导者能读读这本书,进而想方法打消他们所面临的技术阻碍,以反对想要改善其工程效力和文化的企业改革者。 这本书和五大理念无疑将促成业界对DevOps以及其所撑持的数字化转型的了解和利用,并领导领导者和实践者调整其组织构造、文化和技术实际,以进步效力、实现企业指标。 成为你向往的那只独角兽文章的结尾,我想说的是,就像本书所讲的案例故事那样,无论你处于怎么的企业环境和倒退阶段,无论是初创企业还是领有很多技术资产(或技术债权)的传统企业,都能够寻求扭转并取得成功。 无妨以本书中的“五大理念”为指引,逐渐结构正确的企业文化、先进的技术实际以及适当的架构,一直谋求治理翻新和技术创新,造就出可能让企业实现“工程卓越”的“卓越工程师”,置信你们也能够做到独角兽公司所能做到的所有。 当然,你能够从浏览我举荐的这本《独角兽我的项目》开始。 书籍公布预报《独角兽我的项目: 数字化转型时代的开发传奇》 将在4月17日 DevOpsDays 2021·中国上海站进行公布! 即日起扫码报名加入大会,即可收费取得首发图书一本! 即日起通过官网购买DevOpsDays大会上海站门票,即可在图书出版后,取得会务组提供的图书收费支付码。之后您能够在出版社平台下单收费支付《独角兽我的项目》一本。别忘了带去现场签名哦~ 张乐,京东科技京东云事业部高级总监,京东云DevOps产品与研发效力技术总监。DevOpsDays大会与社区中国区外围组织者,国内多个技术峰会联席主席、DevOps专题出品人。EXIN DevOps全系列国内认证官网受权讲师、凤凰我的项目DevOps沙盘受权教练。历任埃森哲、惠普等寰球五百强企业技术专家,多年麻利与DevOps转型、工程效率晋升和大型项目实践经验,胜利主导了大型企业万人规模DevOps一体化平台建设、研发效力体系构建与晋升工作。《独角兽我的项目》中文版译者。 欢送点击【京东科技】,理解开发者社区 更多精彩技术实际与独家干货解析 欢送关注【京东科技开发者】公众号

March 10, 2021 · 1 min · jiezi

关于devops:使用-Puppet-进行配置管理

【注】本文译自https://www.edureka.co/blog/w... 明天,配置管理最成熟的工具是 Puppet。然而,我想您肯定想晓得为什么 Puppet 如此受欢迎、与其余配置管理工具相比,它有什么独特之处。 什么是 Puppet? Puppet 是配置管理工具,用于部署、配置和治理服务器。它具备以下性能: 为每个主机定义不同的配置,并继续检查和确认主机上是否存在所需的配置,是否没有批改(如果批改后的Puppet将复原到所需的配置)动静增减机器规模可管制所有配置机器,从而集中式(基于主服务器或仓储)变更能够主动流传给其余机器 Puppet 应用主从架构,主从之间通过 SSL 应用平安的加密通道进行通信。 晓得了什么是 Puppet,上面让咱们理解 Puppet 为什么会如此受青眼。 要害指标 上面是无关 Puppet 的关键因素: 宏大的装置群体:Puppet 在寰球超过 30,000 家公司中应用,包含 Google、Red Hat、Siemens 等,以及斯坦福大学和哈佛法学院等几所大学。并且每天均匀有 22 个新组织首次应用 Puppet。宏大的开发人员根底:Puppet用处宽泛,很多人都在为它开发。Puppet 的外围源代码有许多贡献者。长期商业应用:Puppet 2005 年已投入商业应用,并且始终在不断完善和改良。它曾经部署在十分宽泛的基础架构(5,000多台计算机)中,同时在这些我的项目中所积攒的性能和可伸缩性教训为 Puppet 的倒退做出了奉献。文档:Puppet 有一个大型的用户保护的 Wiki,其中蕴含数百页的文档以及无关语言及其资源类型的全面参考。此外,它还在多个邮件列表中进行了踊跃的探讨,并领有一个十分受欢迎的 IRC 频道,因而,无论你有什么问题,都能够轻松找到答案。平台反对:Puppet Server能够在反对ruby的任何平台上运行,例如:CentOS,Microsoft Windows Server,Oracle Enterprise Linux等。它不仅反对新的操作系统,而且还能够在绝对老旧的操作系统和 Ruby 版本上运行。 当初很显著,Puppet在寰球范畴内有微小的需要。然而,在深入研究 Puppet 之前,我首先解释什么是配置管理及其重要性。 配置管理 系统管理员通常执行重复性工作,例如装置服务器,配置这些服务器等。他们能够通过编写脚本来主动执行此工作,然而在大型基础架构上工作时,会十分繁琐。 为了解决这一问题,引入了配置管理。 配置管理是一种系统地解决变更的实际,以便零碎随着工夫的推移放弃其完整性。配置管理(CM)确保零碎的以后设计和构建状态是已知的,良好的和可信赖的;并且不依赖开发团队的隐性常识。它容许拜访精确的零碎状态历史记录,以进行项目管理和审计。配置管理克服了以下挑战: 因为需要变更而带来的从新实现。对于新公布但有缺点的版本,可还原到先前版本。因为无奈确定组件类型而导致公布谬误的组件。 让咱们通过一个用例来理解它的重要性。 我晓得的最好的例子产生在纽约证券交易所(NYSE)。一个软件“故障”使纽交所在近90分钟的工夫内无奈进行股票交易,造成了数百万美元的损失。这是因为装置新软件所导致,该软件已装置在其20个交易终端中的8个上,并且该零碎已在前一天早晨进行了测试。然而,晚上,它在8个终端上无奈失常运行。因而,必须切换回旧软件。您可能会认为这是纽约证券交易所配置管理流程的失败,但实际上这正是它的胜利之处上:通过适当的配置管理流程,NYSE 在90分钟内中恢复正常,速度十分快。如果问题继续更长的工夫,结果将更加重大。 当初,心愿您理解配置管理的重要性。配置管理阶段能够看作是 DevOps 的骨干。它容许以最平安,最牢靠的形式更频繁地公布软件。 接下来,让咱们来看看 Puppet 的一些利用。 Puppet 的利用 让咱们通过一个案例来理解 Puppet 的利用。如果您是扑克爱好者或已经玩过在线游戏,那么您肯定曾经据说过 Zynga。它是世界上最大的社交游戏开发商。Zynga的基础设施在公共云和公有数据中心都应用了数以万计的服务器。晚期,他们应用手动流程,包含 kickstarter 和 post 装置,以使数百台服务器上线。 当初,咱们将看到他们在此过程中面临哪些问题: ...

March 5, 2021 · 1 min · jiezi

关于devops:选择正确DevSecOps解决方案的七个技巧

抉择正确DevSecOps解决方案的七个技巧 引言随着越来越多的公司意识到将安全性集成到其DevOps流水线的重要性,对DevSecOps产品的需要始终在强劲增长。然而,投入DevSecOps市场寻求抉择的IT和DevOps业余人员很快意识到,DevSecOps工具和框架的数量泛滥且令人困惑。抉择过多,往往使他们陷入决策疲劳和剖析瘫痪的地步,因为他们试图理解抉择哪种平安解决方案以及如何将其集成到他们的软件开发流水线中。 然而,为什么首先将DevSecOps成为如此关注的焦点呢?为了跟上翻新的步调,开发人员已成倍地减少了对开源软件(OSS)的应用,使其现已广泛应用于利用程序开发交付过程中。随着越来越多的源代码来自“内部”,现在,收集和了解其内容的需要变得至关重要。 在这篇文章中,咱们将钻研在加重OSS中可能蕴含的破绽方面最胜利的工具和技术类型。而后,咱们将分享一些技巧,这些技巧将帮忙您从市场上怀才不遇,并在评估市场上的许多不同选项时做出更好,更理智的决策,尤其是在软件组成剖析(SCA)畛域。 开发的事实&现状现在,典型的应用程序应用多达90%的OSS组件,这些组件取自公开可用的开源库。这种趋势使得应用程序中存在的破绽数量一直减少,进而导致破绽攻打和毁坏。公司通过载DevOps流水线中增加更多安全检查集成来做出反馈。 然而,平安业余人员和开发人员真正须要哪种类型的工具来确保其生产软件的安全性和稳定性?偏心地说,有多种宽泛的DevOps平安工具能够解决软件开发生命周期(SDLC)的不同畛域: 代码剖析(动态和动静)软件组成剖析(针对第三方OSS)运行时安全性剖析(包含容器)现实状况下,团队应该致力于采纳所有这些畛域的工具,以实现残缺的SDLC安全性,然而对于本博客,咱们将专一于软件组成剖析,该软件的指标是缓解OSS开源组件和二进制文件中的破绽和违反许可证合规性。 DevSecOps的七个必备条件抉择DevSecOps工具时,须要确保以下7点: 1、能够本地治理和了解所有制品的工具 在团队在没有实现确定哪个OSS组件具备破绽的工作之前,他们首先须要一个通用的DevOps平台,该平台能够作为一个根本要求,在集中地位治理所有组件和二进制制品文件,而不管其技术栈类型如何。DevOps平台须要晓得我的项目应用了哪些组件以及它们之间的依赖关系,还有我的项目创立了哪些制品文件。 2、应用最好的燃料 最无效的解决方案将须要像VulnDB这样的世界一流的破绽情报源的力量,以确保它具备最新的破绽知识库。世界上最好的汽车如果他们没有最好的燃料来推动他们什么也不是 3、保持可见性和影响剖析 DevSecOps的“赢家”不仅可能理解您的二进制文件应用了哪些OSS库和组件,而且还能理解如何解压和扫描它们并查看所有底层和依赖项,甚至包含打包在Docker映像和zip文件中的那些底层和依赖项。可能理解组织中制品文件和依赖关系构造的解决方案能够为企业提供软件交付可见性,并在交付过程中的任何中央发现其破绽或许可证违规的影响范畴。 4、须要反对容器和云原生框架 解决方案应反对基于容器的公布框架,容器框架已迅速成为云原生部署的事实上的规范。对容器技术的深刻,递归的了解以及深刻探索每一层layer的能力将确保破绽不会被覆盖。可怜的是,某些扫描工具不反对容器,或者对它们的所有不同层和可传递依赖项理解有余。 5、自动化治理 与公司安全部自动化合作治理的能力是DevSecOps的重要筹码。治理零碎必须可能主动执行公司策略,并在不进行干涉的状况下采取相应的措施。次要性能应包含: 通过不同的渠道(例如电子邮件,即时消息或需要管理系统如Jira)来告诉违反安全性或合规性问题。主动阻止蕴含问题(破绽或许可证违规)制品的下载使依赖软弱组件(蕴含高危破绽)的构建失败避免部署易受攻击的交付件6、遍布整个流水线 DevSecOps中的差异化点是如何将制品的具体数据与横跨制品仓库,构建,部署,运行等阶段的平安扫描联合起来。即便在生产部署之后(运行时),一个能够笼罩整个SDLC并继续检测和监督破绽和合规性违规的平台将怀才不遇。 7、混合能源 即便您尚未保护混合型的基础架构。当初抉择反对您的继续云计算旅程和基础架构混合的工具和解决方案,将确保您无论在何处的DevSecOps流水线中都具备一致性和规范。 总结DevSecOps将不再停留在CIO的宿愿单。当初它是必须执行的IT策略,它必须成为任何组织SDLC不可或缺的一部分。即便组织抉择了适合的DevSecOps解决方案,领导者也须要确保他们在各个团队之间施行欠缺的DevSecOps流程。这包含须要持续就应用程序平安最佳实际对开发人员和DevOps从业人员进行培训。开发人员安和全业余人员比例通常是250:1,因而在开发团队之间分享平安常识是补救平安缺失的根底。 抉择一个能够治理存储库,二进制文件,CI / CD自动化和OSS组件剖析并反对容器化公布框架的DevSecOps平台仿佛是一项艰巨的工作。此外,反对本地,云,多云和混合部署是一个额定的挑战。然而,解决方案需要清单是一个很好的终点。咱们心愿这七个技巧将为您向供应商提出正确的问题,打消市场乐音以及做出理智的决定奠定松软的根底。

March 5, 2021 · 1 min · jiezi

关于devops:微服务指南

【注】本文节译自: Microservices Guide (martinfowler.com) 简而言之,微服务架构格调是一种将单个利用程序开发为一组小型服务的办法,每个小服务都在本人的过程中运行,并与轻量级机制(通常是 HTTP 资源 API)进行通信。这些服务围绕业务性能构建,并且能够通过全自动部署机制独立部署。这些服务能够用不同的编程语言编写,应用不同的数据存储技术,只有进行最小化的集中管理。-- 詹姆斯·刘易斯和马丁·福勒(2014)martinfowler.com上无关微服务的资料指南。马丁·福勒2019.8.21 2013年底,在我的圈子里听到了无关微服务的所有探讨后,我开始放心微服务的定义不明确(这种命运给SOA带来了许多问题)。因而,我和共事詹姆斯·刘易斯(James Lewis)聚在一起,他是这种格调的资深从业者之一。 咱们一起写 咱们写这篇文章是为了对微服务格调提供一个明确的定义,咱们通过列出咱们在该畛域中看到的微服务架构的独特特色来实现这一点。 通过服务实现组件化围绕业务能力进行组织产品不是我的项目智能端点和哑管道扩散治理扩散数据管理基础设施自动化故障设计进化设计 咱们还钻研了一些常见问题,例如“微服务的规模有多大”以及“微服务与面向服务的体系结构之间的区别是什么”。这篇文章激发了人们对微服务的趣味。“咱们应用它,咱们不应用它?……这到底是什么呢?” 在简短的介绍性演讲(约25分钟)中,我抉择了最重要的定义特色,将微服务与整体组件进行了比拟,并概述了将第一个微服务零碎投入生产之前要做的重要工作。 咱们什么时候应该应用微服务? 任何架构格调都须要衡量:咱们必须依据它所应用的上下文来评估其优缺点。微服务必定是这种状况。只管它是一种有用的体系结构,但实际上,大多数状况下,应用整体组件会更好。 微服务提供劣势...弱小的模块边界:微服务增强了模块化构造,这对于大型团队而言尤其重要。独立部署:简略服务更易于部署,并且因为它们是自治的,因而出错时不太可能导致系统故障。技术多样性:应用微服务,您能够混合应用多种语言、开发框架和数据存储技术。…但要付出代价分布式:分布式系统较难编程,因为近程调用速度很慢,并且总是面临失败的危险。最终一致性:对于分布式系统而言,放弃强一致性十分艰难,这意味着每个人都必须治理最终一致性。经营复杂性:您须要一个成熟的经营团队来治理大量服务,这些服务会定期重新部署。微服务高级版 在过来的一年里,微服务架构格调始终是热门话题。在最近的 O'Reilly 软件架构会议上,仿佛每个会议都在议论微服务。足以使每个人的“适度炒作检测器”启动并闪动起来。其结果之一是,咱们曾经看到团队太渴望承受微服务,而没有意识到微服务会给本人带来复杂性。这给我的项目的老本和危险减少了额定的费用---这通常会使我的项目陷入重大的麻烦。马丁·福勒(Martin Fowler)2015.5.13整体优先 当我听到团队应用微服务架构的故事时,我留神到了一种常见的模式。 简直所有胜利的微服务故事都始于一个宏大的整体,并且被合成了我据说过的从头构建为微服务零碎的零碎都遇到了重大的麻烦。不要从整体开始 在过来的几个月中,我反屡次听到这样的说法:获得成功的微服务架构的惟一办法就是首先从整体开始。用西蒙·布朗(Simon Brown)的话来说:如果您无奈构建构造良好的整体,那么为什么您认为能够构建一组构造良好的微服务呢?最近(通常是十分有说服力的)的论点来自该站点上的马丁·福勤。当我有机会对晚期的草案发表评论时,我有一些工夫来思考这一点。 我之所以这样做,尤其是因为我通常会发现自己与他统一,而其余一些我通常分享的观点仿佛也批准他。我深信从整体开始通常是谬误的做法。斯蒂芬·蒂尔科夫(Stefan Tilkov)2015.6.9微服务先决条件 当我与人们议论应用微服务架构格调时,我听到了很多乐观情绪。开发人员喜爱应用较小的单元,并且冀望比整体组件具备更好的模块化。然而,与任何架构决策一样,都须要衡量取舍。尤其是对于微服务而言,这给经营带来了严重后果,运营者当初必须解决小型服务的生态系统,而不是一个定义良好的繁多整体。因而,如果你没有某些根本能力,就不应该思考应用微服务格调。马丁·福勒(Martin Fowler)2014.8.28微服务和分布式对象的第一定律 在 EAA 的 P 中,我说“不要散发您的对象”。 这个倡议是否与我对微服务的趣味相矛盾?马丁·福勒(Martin Fowler)2014.8.13与萨姆·纽曼(Sam Newman)对于微服务的访谈 goto会议要求我对萨姆·纽曼的书《Monoliths to Microservices》进行采访。这变成了无关微服务及其何时应用它们的一般性探讨。萨姆认为它们的三个次要起因是独立的可部署性、数据的隔离性和反映组织构造。我对第一个更为狐疑,但认为数据和人员是软件开发的简单局部。马丁·福勒(Martin Fowler)2020.9.4构建微服务 微服务架构是相当新的,但我很侥幸,自从最早呈现以来,咱们就始终在 ThoughtWorks 与它们单干。对于如何最好地与他们单干的最好形容,最好的介绍是萨姆·纽曼(Sam Newman)的书《构建微服务》,他依据咱们的教训和其余已发表的教训撰写了这本书。 微服务架构中的测试策略 在过来的几年中,基于服务的架构已转向更小、更集中的“微”服务。这种办法有很多益处,例如可能独立部署、扩大和保护每个组件,并使多个团队之间的开发并行化。然而,一旦引入了这些额定的网络分区,就须要重新考虑利用于单片过程利用的测试策略。在这里,咱们打算探讨一些办法,用于治理多个可独立部署的组件的额定测试复杂性,以及在多个团队各自充当不同服务的监护人的状况,如何让测试和利用放弃正确。托比·克莱姆森(Toby Clemson)2014.11.18如何将单体利用合成为微服务 随着整体零碎变得太大而无奈解决,许多企业偏向于将其合成为微服务架构格调。 这是一次值得的旅程,但并不容易。 咱们曾经理解到,要做到这一点,咱们须要从简略的服务开始,而后再基于对业务很重要并且会常常更改的垂直性能来提供服务。这些服务起初应该很大,最好不依赖于其余的整体。咱们应该确保迁徙的每一步都代表了整个体系结构的原子性改良。扎马克·德加尼(Zhamak Dehghani)2018.4.24微前端 好的前端开发很难。扩大前端开发,使许多团队能够同时解决大型简单产品,这变得更加艰难。在本文中,咱们将形容最近的一种趋势,行将前端整体拆分成许多更小、更易于治理的局部,以及这种架构如何进步前端代码团队的效率。除了探讨各种收益和老本外,咱们还将介绍一些可用的实现选项,并深入研究演示该技术的残缺示例利用。卡姆·杰克逊(Cam Jackson)2019.6.19如何从整体中提取数据丰盛的服务 当将整体式服务器拆分成较小的服务时,最艰难的局部实际上是拆分存在于整体式数据库中的数据。要提取数据丰盛的服务,遵循一系列步骤始终保持数据的单个写正本是很有用的。这些步骤首先在现有的整体中进行逻辑拆散:将服务行为拆分为独自的模块,而后将数据拆分为独自的表。这些元素能够别离挪动到新的自治服务中。普拉富尔·托德卡尔(Praful Todkar)2018.8.30基础设施即代码 基础架构即代码是通过源代码定义计算和网络基础架构的办法,而后能够像看待任何软件系统一样看待它们。能够将此类代码保留在源代码管制中,以容许可审核性和可复制的构建,服务从于测试实际,以及继续交付的残缺标准。在过来的十年中,这种办法已用于应答一直增长的云计算平台,并且将成为下一个解决计算基础架构的次要办法。马丁·福勒(Martin Fowler)2016.3.1DevOps 文化 麻利软件开发突破了需要剖析、测试和开发之间的一些孤岛。部署、操作和保护是其余流动,它们与其余软件开发过程有着相似的拆散。DevOps 静止旨在打消这些孤岛,并激励开发与经营之间的合作。鲁安·威尔森纳赫(Rouan Wilsenach)2015.7.9熔断器 对于软件系统,通常是近程调用运行在不同过程中的软件,可能是在网络中的不同计算机上。内存内调用和近程调用之间的最大区别之一是,近程调用可能会失败,或者挂起而没有响应,直到达到某个超时限度。更蹩脚的是,如果您在没有响应的供应商上有许多调用者,那么您可能会耗尽要害资源,从而导致多个零碎之间的级联故障。 迈克尔·尼加德(Michael Nygard)在他的优良著述《开释它》(Release It)中推广了断路器模式,以避免这种灾难性的连锁反应。 熔断器的基本原理非常简单。将受爱护的函数调用包装在熔断器对象中,该对象将监督故障。 一旦故障达到某个阈值,熔断器将跳闸,并且所有进一步的熔断器调用都会返回谬误,而基本不会进行受爱护的调用。通常,如果熔断器跳闸,您还须要某种监控器警报。马丁·福勒(Martin Fowler)2014.3.

March 5, 2021 · 1 min · jiezi

关于devops:jenkinsk8s的CICD流程设计

前言在jenkins的根底上,设计CICD流程。具体流程如下: 拉取代码代码扫描构建镜像并推送到仓库部署到k8s音讯告诉一、流程阐明1.1 环境阐明两套k8s环境,分为开发测试环境(dev)和生产环境(pro),同时,镜像仓库也分为两套。两套环境都能连贯上git和jenkins。注:dev和pro需在物理上进行隔离。 1.2 流程需创立两条流水线:dev流水线:研发编码实现后,将代码提交到仓库,触发构建流程,先进行代码扫描,再生成镜像并推送到dev仓库,主动部署到开发测试环境。所有功能测试验证通过后。pro流水线:运维手动触发流水线,将dev仓库的镜像推送到pro仓库,部署到线上环境。注:上线前需思考预公布,比方蓝绿部署,金丝雀部署等,后续再进行欠缺。 二、代码构造创立一个新工程,以单体flask利用为例,须要蕴含以下文件。├── Dockerfile # 镜像构建文件├── deploy │   ├── dev # dev环境部署文件│   └── pro # pro环境部署文件└── tests 三、jenkins配置3.1 装置通过docker装置,将数据目录挂载到本地门路。 docker run \ -u root \ --rm \ -d \ -p 8080:8080 \ -p 50000:50000 \ -v jenkins-data:/opt/jenkins_data \ -v /var/run/docker.sock:/var/run/docker.sock \ jenkinsci/blueocean3.2 装置plugins进入【系统管理】-【插件治理】,装置以下组件。docker-build-stepSonarQube Scanner for JenkinsKubernetes Continuous Deploy Plugin 3.3 配置凭据3.3.1 github进入【凭据】-【零碎】-【全局凭据】,点击【增加凭据】,抉择类型【Username with password】。注:以后采纳账号密码的模式,倡议采纳token的形式来配置github的凭据。 3.3.2 harbor 3.3.3 sonarqube生成sonarqube的token。 增加【secret text】凭据。 3.3.4 k8s3.3.5 音讯推送四、流水线4.1 dev流水线dev流水线的流程如下:代码拉取-代码扫描-镜像构建及推送-部署 登录jenkins,【新建工作】,抉择【构建一个自在格调的软件我的项目】。 4.1.1 代码拉取点击【源码治理】,抉择git,填入仓库地址,抉择GitHub的凭证。默认分支为master,批改为以后开发的分支。 ...

February 27, 2021 · 1 min · jiezi

关于devops:jenkinsk8s的CICD流程设计

前言在jenkins的根底上,设计CICD流程。具体流程如下: 拉取代码代码扫描构建镜像并推送到仓库部署到k8s音讯告诉一、流程阐明1.1 环境阐明两套k8s环境,分为开发测试环境(dev)和生产环境(pro),同时,镜像仓库也分为两套。两套环境都能连贯上gitlab和jenkins。注:dev和pro需在物理上进行隔离。 1.2 流程需创立两条流水线:dev流水线:研发编码实现后,将代码提交到仓库,触发构建流程,先进行代码扫描,再生成镜像并推送到dev仓库,主动部署到开发测试环境。所有功能测试验证通过后。pro流水线:运维手动触发流水线,将dev仓库的镜像推送到pro仓库,部署到线上环境。注:上线前需思考预公布,比方蓝绿部署,金丝雀部署等,后续再进行欠缺。 二、代码构造创立一个新工程,以单体flask利用为例,须要蕴含以下文件。├── Dockerfile # 镜像构建文件├── deploy │   ├── dev # dev环境部署文件│   └── pro # pro环境部署文件└── tests

February 26, 2021 · 1 min · jiezi

关于devops:50有用的DevOps工具四

原文: https://dzone.com/articles/50...翻译: 祝坤荣31.SolarWinds 服务与利用监控Solarwinds的服务与利用监控,提供了不错的个性列表。 Link: https://www.solarwinds.com/server-application-monitor 测试33.Vegeta一个可被当成命令行或类库的HTTP压力测试工具。Link: https://github.com/tsenart/vegeta 34.QuerySurgeQuerySurge次要专一在如何自动化校验和测试你的数据。其值得一提的个性是其对于多平台的反对,与大多数数据集成与BI测试计划的内置反对。 Link: https://www.querysurge.com/ 平安 35.KryptonKrypton是一个应用了不易损坏的加密架构的U2F验证挪动利用。所有的加密密钥都存储在本地驱动器,来避免不想遇到的内部攻打。 Link: https://krypt.co/ 36. Mysterium.networkMysterium为Mysterium终端用户提供隐衷和平安的一种网络节点。这种节点镜像是为树莓派这种嵌入式零碎硬件筹备的。 Link: https://mysterium.network/ 37.OktaOkta是一种鉴定治理服务。通过Okta,你能够在一处治理所有雇员的拜访,Okta的个性包含单点登录(SSO),AD与LDAP集成,多因子验证(MFA)。所有这些都随提供了多种整合计划的Okta集成网络提供。 Link: https://www.okta.com/ 38.Palo Alto Networks一家提供云平安服务的公司。服务包含为从分支机构的移动用户提供平安接入。数据保护,治理,合规,安全监控,合规验证,云存储平安。 Link: https://www.paloaltonetworks.com/cloud-security 39.Small step SSHSmallstep提供单点登录SSH(SSO SSH),能让你不必每天收集,发送,解决SSH。所有SSH和sudo的拜访都能够从一个管理员版面进行治理。 Link: https://smallstep.com/sso-ssh/ 有用的CLI工具40.Awless一个指标是帮忙开发者治理亚马逊web服务的命令行工具。Awless Link: https://github.com/wallix/awless 42.Snyk-CLISnyl CLI能帮你找到,更重要的帮你修复依赖项的破绽-无论是热点网络或你的CI零碎。 Link: https://support.snyk.io/hc/en-us/categories/360000456217-Snyk-CLI 43.DaytonaDaytona通过提供更有效率的专一于自动化验证与密钥获取的Vault客户端版本来辅助你。 Link: https://github.com/cruise-automation/daytona 开发44.BitbucketBitbucket是为业余团队提供的,集我的项目打算,代码合作,测试,开发一体的产品,同时也提供订阅服务选项。 Link: https://bitbucket.org/product 45.ConfluenceConfluence是一个对于我的项目打算,会议纪要,市场打算,博客公布很现实的工具。为你的业务提供一个凋谢和可存取的空间,对于团队和公司都很适合。 Link: https://www.atlassian.com/software/confluence 46.Frame.aiFrame提供一个对于你客户关系的独特视角并通过继续监控的个性帮忙你辨认出客户后果背地的为什么。 Link: https://frame.ai/ 47.GritGrit帮忙程序员/开发者从原仓库存储,传送,分享和复制代码提交到指标仓库。 Link: https://github.com/grailbio/grit 48.JIRAJira帮忙开发者在预约的工作上捕捉,调配和设定优先级。它帮忙开发者治理整个软件开发过程,保障所有工作都曾经实现。 Link: https://www.atlassian.com/software/jira 49.EditorConfigEditorConfig帮忙在大型群组应用不同编辑器或IDE工作的开发人员保护一套统一的编码标准。 Link: https://editorconfig.org/ 50.TilixTilix是用来模仿合乎gnome人机界面标准的linux终端模拟器。它能够创立多个能够被同步的控制面板。 Link: https://gnunn1.github.io/tilix-web/ 51.JsonnetJsonnet是一个容易了解的JSON扩大。这个工具提供了很多个性,如打消反复,与自定义/现存利用整合,并能生成包含JSON,INI,YAML格局的内容。 Link: https://jsonnet.org/ ...

January 30, 2021 · 1 min · jiezi

关于devops:还在写定时任务进行部署使用Artifactory-Webhooks和Docker实现持续部署

引言继续部署(CD) 是在继续集成的根底上,把集成代码或构建产物自动化部署到测试或生产环境。这就是咱们所说的“流动软件”。齐全自动化能够使您的部署无缝、更少的出错几率、更快,并且能够缩短反馈循环,因为您当初能够在每次更改之后进行部署。 实现继续部署须要以下因素: 继续集成(CI),如Jenkins或JFrog Pipeline,用于构建/验证新版本。 制品管理器,如JFrog Artifactory,用于存储制品,并提供新版本的部署指标(服务器、智能设施)。 一个部署代理,管制新版本制品的相干运维操作 (进行以后服务器、下载二进制文件、启动服务器)。代理有两种类型: 拉取形式: 在指标上运行的代理 推形式:  在任意集中服务器上运行的代理,近程更新指标服务 两种形式的比照: 拉和推部署模型各有优缺点,您也能够同时应用这两种模型。拉模型最显著的毛病是代理不晓得二进制存储中的更改,因而它不晓得何时触发更新。推送模型的一个毛病是安全性,因为指标须要确保部署代理通过身份验证,并且只能执行受权执行的操作。 在本次分享中,咱们会分享如何创立一个推/拉的解决方案。咱们将一步一步实现从构建推送Docker镜像到注册核心进行验证,并将其降级生产环境,最初应用JFrog Artifactory webhook来触发将其部署到咱们的生产服务器。 1.搭建制品库Artifactory首先,您须要一个运行的Artifactory服务器。如果您还没有云实例,您能够收费创立一个云实例。https://jfrog.com/artifactory... 首先创立两个Docker仓库:Docker-local-staging和Docker-local-prod。 在new repository窗口中: 抉择Docker输出“docker-local-staging”作为key点击“保留并实现”反复上述步骤创立“docker-local-prod”当初你有了两个空的存储库,持续设置webhook。导航到治理菜单 Admin |General| Webhooks,点击“新建webhook“像这样填写: 留神:在这个例子中,URL设置为" http://host.docker.internal:7979/ "。这是因为webhook处理程序将运行在本地主机和端口7979上。这里的host.docker.internal主机名是用来从Docker容器达到主机的。在生产环境中,您可能须要将其更改为您的生产服务器URL和您抉择的端口, Artifactory 当文件有变更会被动告诉该地址所执行的服务。 在secret字段中,您能够输出任何您想要的字符串,它将以HTTP header“X-jfrog-event-auth”模式发送到指标服务,这样您就能够验证查问是否来自可信的源。 抉择“Docker tag was promoted”事件。在Artifactory中,Docker镜像能够被降级(升级,代表测试验证通过,将该镜像降级为更高成熟度状态),这须要在不批改内容的状况下将Docker镜像从一个仓库挪动到另一个仓库。这能够确保在筹备阶段测试的镜像是将验证通过并是行将投产的镜像。 点击“Select Repositories”,而后抉择要从中晋升镜像的仓库。你也能够在“Include Patterns”局部增加一个过滤器来匹配你的Docker镜像清单。 2创立Webhook 处理程序webhook处理程序将在生产服务器上运行,并将接管一个蕴含变更事件信息的HTTP申请。在上述镜像降级的状况下,它的申请数据将看起来像这样: webhook处理程序须要做到以下操作: 读取并解析HTTP音讯体。验证Docker镜像和仓库。即便你在Artifactory的webhook设置中增加了过滤器,服务器也应该总是验证申请输出。拉去最新的Docker镜像。进行正在运行的容器(如果存在的话)。启动新版本。上面是处理程序的外围逻辑。残缺的代码示例能够在Github中找到。 https://github.com/jfrog/project-examples/tree/master/webhook-example func main() { http.HandleFunc("/", func (w http.ResponseWriter, r *http.Request) { ctx := context.Background() p, err := readPayload(r) if err != nil { ...

January 29, 2021 · 2 min · jiezi

关于devops:使用一体式CICD平台

前言匆匆忙忙完结了2020年,想着还是要在2021年的第一个月要写一篇文章。在看了[Gitlab]推送的文章之后,本人也比拟认同在DevOps实际中如果应用一个一体化的CI/CD平台或者工具所能带来的益处。 不过每个组织或者团队有本身的一些考量和理论状况,就比方的以后我在工作中也应用了多个工具来实现整个CI/CD流程,仿佛是拆散了CI和CD的过程,因为公司更加考量了做交付的稳定性和安全性考量,并没有做到齐全的继续公布。 所以这篇文章仅仅是探讨一些一体化CI/CD平台能够带来的劣势。 CI/CD继续继承和交付(CI/CD)扭转了咱们构建,测试和部署软件应用的形式。CI/CD工具自动化这些流程,缩小错误率,并且优化了整个工作流。代码在整个开发阶段中进行自动化测试,已确保在谬误达到生产之前就将其捕捉并修复。 CI/CD工具的应用将继续减少并改善软件开发的形式,应的部署也不再须要是每年一次,每个季度一次,甚至每个月一次。通过CI/CD,开发运维团队能够一天内部署屡次。 10个CI/CD的长处下面说了什么是CI/CD,那接下来咱们看看其有哪些长处。 1. 更少的交接 在开发管道中更多的交接,那将带来更多的故障点和更多的复杂性。 2. 减少开发速度 通过CI/CD,开发的所有阶段都更快,整个过程中更快的迭代速度使每个团队的工作效率更高,开发人员也能够更有信念地转移到其余我的项目。 3. 更多的部署 每两周或更长时间产生一次的公布,当初能够每天推送屡次。 4. 更快的测试 开发工作流程中一个比拟耗时的局部被移除,开发人员能够从事其余高价值的我的项目。自动化测试让团队能够更疾速地取得反馈,并尽早失败,而不是在生产中产生这些谬误,或者更蹩脚地将谬误带到最终的公布版本中。 5. 更少的代码缺点 通过开发流程中引入自动化测试,在代码缺点产生时就能及时捕捉,并防止代码合并入主分支。这样能够确保整体上的具备更高的代码品质,并且每个公布版本都能按预期工作。 6. 加强合规性 合规性工作能够纳入开发生命周期,缩小公布不合规利用的危险。自动化合规查看使得更容易实现审核,并能够避免高代价的谬误。 7. 更多的翻新工夫 破费在集成保护的工夫越少,IT收入不变,也就意味着能够更多的工夫投入到其余中央。 8. 更开心的开发者开发人员可能更有自信地工作和疾速地修复缺点,而不是等上几个星期来理解谬误产生在哪里。 9. 缩小管理费用 组织中开发人员的工夫是无限的,开发工夫是可计费时间的很多倍,而手动测试和部署代码可能会毁坏整个IT估算。自动化的工作流程缩小了手动工作,能够使估算更加无效。 . 流程一致性 开发流程中具备更高的自动化水平意味着没人会遗记该过程中执行的步骤,也使得构建更加统一。这样更容易培训新的开发人员,组织也能够更加容易管制如何构建,以及何时进行公布。 一体式CI/CD劣势下面概述了CI/CD能够带来的益处,然而在理论的实际中,如何真正地掂量生产力速度,须要评估整个软件开发生命周期(SDLC),而不仅仅是点点滴滴。 无缝地继续集成和交付应具备使应用程序为部署做好筹备所需的所有,可怜的是,很多应用CI/CD的组织因为应用的工具而陷入了无奈达到最佳工作流程的窘境。 一个能够在整个软件开发生命周期提供可见性的应用程序是确保和优化每个开发阶段的最佳办法,当一切都在一个屋檐下时,就容易发现流程的瓶颈,以及评估影响开发速度的每一个元素。 在单个DevOps平台下的每个步骤都提供了一条信息,可就是否筹备好合并代码做出理智的决定。当然,所有这些步骤能够在没有一体式CI/CD的解决方案的状况下执行,然而性能全面的工具能够创立繁多的事实起源,在此状况下,能够更快地监督每个步骤,并缩小脱漏谬误的可能性。 一体式CI/CD平台带来以下益处: 整个软件开发生命周期的可见性所有开发阶段的繁多实在起源无需登陆多个应用程序在一个界面上导航更简略只须要装置,保护,扩大,备份一个应用程序更容易的受权治理升高经营费用因而,举荐在组织或团队中构建繁多的CI/CD平台来减速利用翻新,例如抉择应用 Gitlab,Github,以及各大公有云提供商发行的DevOps平台及工具来优化整个CI/CD流水线。 Mengz's Blog

January 25, 2021 · 1 min · jiezi

关于devops:Devops下的接口全生命周期质量建设

什么是devops?随着工夫的推移,devops的定义也在一直的演进。对于其定义可能呈现千人千面,但从外围观点,整体业界还是放弃着统一的意识。DevOps不是繁多的技术或者工具,甚至不只是一个流程,他蕴含利用设计、麻利开发、继续交付和监控运维等一系列流程,波及到企业文化、团队合作流程等多个方面,它能够被了解为一系列能够高速、高质量进行软件开发的工具链。 联合软件生产全生命周期来看,devops落地实际的外围指标是缩短开发周期,进步部署频率和更牢靠的公布。 DevOps的诞生源于企业要适应这个瞬息万变的市场,可能做到继续交付。正如《继续交付2.0》作者在书中精炼的2个环:价值摸索和疾速验证。 疾速验证环的两个外围要害是品质与速度 它会要求以最牢靠的品质和最快的速度,交付最小可行计划,牢靠地收集实在反馈,来造成这样的闭环。对于品质来讲一个外围的实际就是品质内建,有一个公认的事实。那就是在整个继续交付全生命周期过程中,缺点越滞后发现,所须要的老本就越高。品质内建就是要从生产过程中的第一个环节开始,就要重视产出物的品质,并且在每个环节中都要去发展品质保障流动,这就要求在软件全生命周期参加的各个角色都须要实时的对软件的品质负责。确保软件在交付到下一个环节前有了根底的品质保障。其外围目标就是缩小因为品质问题导致的返工,避免浪费大量人力老本。 速度,得益于在软件全生命周期过程中每个环节无效的发展自动化,进而做到“继续”两个字,比方继续构建、继续测试、继续公布、继续运维。 对于疾速验证环,从测试的层面,是如何落地实际的。让咱们聚焦于接口,这个软件产物中必不可少的外围组成部分。从接口的全生命周期登程,介绍接口治理、测试、监控。接下来会围绕网易易测团队输入的接口全生命周期合作平台GoAPI登程,从痛点梳理、平台的设计、测试左移和右移实际、接口监控闭环建设等几个局部论述是如何实现对于接口的“疾速验证环” 1.接口全生命周期什么是接口全生命周期?能够从如下的一张图来了解 联合软件研发流程来看的话,接口全生命周期蕴含了接口定义、编写、测试、上线利用、运维监控、回收下线等阶段。在接口的不同生命周期过程中,围绕着品质内建的思维,其实是需要开发/测试/运维等角色去发展各种品质保障流动。 在实际的过程中,一个典型的景象是接口的品质保障还是测试这个角色在接口测试及回归阶段进行,这种景象呈现可能有两种团队状态,一是开发、测试、运维三个角色分工明确,大家都聚焦于本身角色的一些指标。二是大家都在踊跃的发展着品质流动,然而在施行过程中发现会遇到各种妨碍和痛点。 那么在接口全生命周期中有哪些外围的痛点,能够从以下4点来进行剖析 * 接口定义治理与同步难:传统接口定义多是文档化治理,文档更新则往往不及时,当接口产生变更时,时常不能及时同步到上游的测试团队。 * 自动化门槛高:数据筹备、用例编写、用例执行和工作的编排都有较高的准入门槛 * 角色及应用阶段受限:传统模式下的接口测试只局限于测试人员在版本回归阶段应用,短少合作 * 线上接口监控难:因代码变更导致的接口异样、偶发性的接口谬误、线上服务宕机等异样行为不足无效的监控与发现伎俩。 围绕以上痛点,从品质内建的指标登程,从测试左移和右移的视角去思考,能够看到如下图示的典型问题及阶段变动 * 第一个问题:测试须要更多的工夫关注在接口定义层面 从接口定义开始,波及到一个外围点在于接口治理,目前的一些治理形式中蕴含Swagger和Postman等模式,相似Swagger这种治理属于动态的,在接口变更时不足及时性告诉机制,往往会存在测试人员在测试过程中才会发现接口曾经产生变更,这无疑会导致我的项目交付周期缩短。 * 第二个问题:接口自测冒烟在开发与测试之间没有造成很好的合作。 同一件事件被多人反复做了开发人员在开发完一个API接口,会部署到开发环境中,而后通过本人写自动化脚本或者利用 POSTMAN工具验证一下这个API 接口是否合乎预期,这时候其实曾经做过一个简略的API测试了。到了提测阶段开发会将写好的API接口文档给测试人员,测试人员会部署代码到测试环境中去,而后通过 TestNG 或者其余自动化测试框架写接口测试用例,咱们发现,API的正向用例测试,开发人员做过一次,测试人员用不同的形式又做了一次? 开发提测的品质不可度量 开发人员提测,测试人员进行冒烟验收,个别只是执行一下冒烟测试用例,提交接口文档,口头叙述一下这些接口我在开发环境都验证通过,合乎提测规范了。然而对于测试人员来讲这个口头叙述是没法来度量提测的品质的,测试人员短少主观的数据来评估接口的品质是否合乎预期,从而导致前期因为品质问题呈现版本回退的景象,迁延了版本交付周期。 * 第三个问题:API 接口的变动引起的叠加效应 API 接口变动是常有的事件,然而现有的流程中,一个接口的变动会牵扯出一系列的变动,接口文档的变动,接口测试用例的变动,接口测试代码的变动,继续集成的变动......, 工夫老本霎时进步。有没有方法只有一个中央批改了这个变动,那么其余所有的事件都解决了呢? 围绕着接口全生命周期治理与测试中的典型痛点及多角色间合作的问题,网易易测通过多年的技术教训积攒和业务实际,打造了GoAPI接口合作平台。它是围绕接口全生命周期治理、晋升研发与测试效率为指标的团队合作平台。平台提供便捷的接口治理,无门槛与多维度的自动化测试,欠缺的OpenAPI扩大等多种丰盛能力,大幅升高企业研发和测试老本。 接下来会重点介绍它的设计思路和利用实际 2.整体设计思路 从外围指标、设计理念、实际利用的几个维度来看下整体的设计思路 * 外围指标:缩小投入老本和减少收益 针对接口治理与测试,须要关注的一个外围是投入产出比,这会波及到两个指标:缩小投入老本、减少收益。缩小投入老本能够从以下几个方向去思考:缩小用例编写的老本、缩小用例保护优化的老本、缩小依赖工具开发、数据结构的老本。而减少收益,咱们都晓得自动化每执行一次它就施展一次价值,那么减少使用率,也就能减少收益;而要做到减少使用率有几个方面能够思考去施行:做到人人能用,手工能用、能当工具用、同时接口全生命周期各个阶段都能用。 * 设计理念:可视化、可合作、可追溯 可视化,须要做到2个0,0框架入门老本,如此能力不须要再关注自动化框架要如何去做封装,如何去做业务分层和数据驱动等等;0编码用例编写,只须要拼装好参数执行就能够,不再吐糟这是谁写的测试代码。 可合作,在后面剖析痛点的过程中一个很重要的点就是多角色共建共用;何谓共建,开发与测试共同完成接口测试用例,何谓共用,让每一个角色都可能轻而易举的去应用已有的接口自动化测试案例 可追溯,真正实际的过程中,当接口量级达到1万+时,可追溯就变得很重要了,其中会蕴含失败剖析,得具备便捷高效的疾速定位的能力。同时要针对性的开展数据统计分析,从不同维度和不同粒度去发展。 3.利用实际 能够看到整个接口全生命周期的各个角色都围绕着GoAPI在施行流动,以上是一个单产品的统计数据,达到了1万+接口,5万+用例,5千万+执行次数。在整个实际利用过程中涵盖了接口生命周期的各个阶段,从定义接口契约开始,调试能够一键mock,不须要再另外搭建mockserver,接口自测冒烟及验收,开发只需自测实现后增加一个执行集,测试就能够一键实现冒烟验收平台能够定时继续集成并蕴含多维度告诉机制,同时蕴含了当接口契约产生变更时,其余所有环节会同步产生变更,以达到一键变更的目标。 测试左移实际 测试环的疾速验证 利用GoAPI建设在测试环节围绕接口的疾速验证,将GoAPI建设的接口自动化能力接入到继续集成、公布过程、线上回归阶段。 联合公布平台施行PE公布验证 某个业务线上利用集群上百台机器,而线上回归执行运行一次不能残缺笼罩到每台机器上利用实例的可用性,可能会造成某台利用实例因为不可知因素带着问题上线,导致线上故障。那么对于PE而言,他们的诉求是心愿每次公布的每一台利用实例都是通过自动化回归过的,基于此,联合外部公布平台实施方案如下,个别的公布平台都应该具备以下步骤:offline、deploy、check、online;先将以后实例下线,接着部署,而后check服务可用性,最初online到线上提供服务。只是以后check这一步只是健康检查,而非服务功能性验证。那么如此能够基于check扩大去调用GoAPI openAPI施行自动化执行,通过后再主动online。 通过这个计划施行后,PE每次公布再也不会“胆战心惊”,因为每一个利用实例都是通过全量接口回归后上线的。 测试右移:接口监控 从接口全生命周期来看,还有“最初一公里”须要去攻克,那就是线上接口监控。首先咱们从整体的业务品质监控来看,须要依赖于业务品质监控和系统资源监控两者造成互补。 系统资源监控次要是贴近系统资源,从服务器、数据库、中间件、利用异样、网络等资源开展监控,然而其中的局限在于难以直观评估线上用户理论影响。 业务品质监控次要是贴近业务性能场景,从接口监控、UI监控、指标监控、舆情监控等方面开展,可用于评估线上业务影响。 ...

January 15, 2021 · 1 min · jiezi

关于devops:Terraform初体验二-第一个demo执行

通过Terraform在本地运行docker nginx前置条件: 1. 装置好windows docker 2. 装置好terraform 装置docker装置windows docker能够间接登录http://docker.com下载安装即可,docker能够有图形化治理页面装置最新的19.03。为了简化第一次的操作,这里咱们先不通过terraform来装置docker,docker下载安装地址https://www.docker.com/get-started 编写main.tfterraform { required_providers { docker = { source = "terraform-providers/docker" } }}provider "docker" { host = "tcp://localhost:2375"}resource "docker_image" "nginx" { name = "nginx:latest" keep_locally = false}resource "docker_container" "nginx" { image = docker_image.nginx.latest name = "tutorial" ports { internal = 80 external = 8000 }}其中值得注意的是,官网的例子,在provider "docker"中指定的host是通过windows的管道实现的,怕是曾经很多人不会用了。这里须要在docker desktop中设置开启"tcp://localhost:2375",并替换tf文件中的host ="tcp://localhost:2375"。 执行main.tf笔者应用的vs code,能够间接右键在终端中关上,而后顺次进行以下步骤。 1. 初始化在终端中执行terraform init。首次执行初始化操作,会有较长的工夫去获取terraform中定义的source信息,在第一次初始化后没有source信息的变动,能够跳过初始化间接开始部署。 2. 部署在终端中执行terraform plan查看terraform执行打算,在终端中执行terraform apply实现部署。执行部署命令时,会将terraform的plan列出来展现给用户,并由用户确定执行。也能够输出-auto-approve跳过plan。 ...

January 11, 2021 · 1 min · jiezi

关于devops:50有用的DevOps工具三

原文: https://dzone.com/articles/50...翻译: 祝坤荣22.LookerLooker,当初是Google云的一部分,是一个可与Redshift,Snowflake,BigQuery,以及超过50种SQL方言无缝集成的商业智能与数据分析平台。通过Looker,你能够取得对你数据前所未有的洞察力。 链接:https://looker.com/ 23.Apache HadoopHadoop从开始就被设计成易于扩大,它的框架能让大型数据集散发到一台或千台服务器上。它也提供一个设计成能在本地实现计算与存储的库。 链接:https://hadoop.apache.org/ 24.HPCC SystemsHPCC Systems通过其在数据行业20年的教训提供给你收费和开源端到端的数据湖平台。 链接:https://hpccsystems.com/ 25.BigQuery由Google带给你,它是搜索引擎对于serverless,节约老本,可扩大数仓的答案。 链接:https://cloud.google.com/bigquery 26.Apache CassandraCassandra是在要害数据畛域的可用工具,它保障失败迁徙和线性可扩大,Cassandra保障你的数据库始终维持在一个高水位的扩展性和可用性。 链接:https://cassandra.apache.org/ 27.MongoDBMongoDB通过将数据存储成JSON文档这种非凡的形式,这使零碎有极好的灵活性,扩展性和动态性。MongoDB置信这使存储数据的现实形式,你能够本人看看,看是否批准。 链接:https://www.mongodb.com/ 28.Qlik通过Qlik的QlikSense和QlikView,你的原始数据能够变得极具可操作性, Qlik应用它的端到端形式进行数据整合与剖析,来将你数据最大化转化成你的业务可能增长方向的洞察数据。 链接:https://www.qlik.com/us/ 29.SisenseSisense是构建和部署剖析利用的背地驱动力。Sisense数据与剖析平台提供旨在将简略数据变成无效剖析工具的麻利商业智能零碎。 链接:https://www.sisense.com/ 30.Talend最后在2005年公布,Talend曾是第一家提供数据集成软件的开源商业软件提供商,并当初仍是这个畛域的领导者。 链接:https://www.talend.com/ 监控 31.SensuSensu提供从单服务器到云级别的多云监控。Sensu曾经与你在应用的平台集成并提供通过Sensu SSO实现的强平安保障。 链接:https://sensu.io/ 本文来自祝坤荣(时序)的微信公众号「麦芽面包,id「darkjune_think」转载请注明。 交换Email: zhukunrong@yeah.net微博:祝坤荣开发者/科幻爱好者/硬核主机玩家/业余翻译

January 11, 2021 · 1 min · jiezi

关于devops:Mobile-DevOps-之-Proxmox-实现节流提效

作者:蒋伟 网易云信客户端首席架构师 简介2020年,挪动互联网 DevOps 畛域显现出了规模化经营的趋势,少数 App 研发大厂均装备了上百人的研发团队规模,编译计算的诉求也是一劳永逸,用自动化测试节约人力的行为也是不断涌现。Mobile DevOps 在解决大规模编译、自动化测试、交付路上的挑战十分艰巨,但在新冠疫情的背景下,研发估算却趋于激进,如何在这个时代背景下解决高增长的计算需要与低估算之间的矛盾,成了一个亟待解决的难题。 本文将介绍 Proxmox 在网易智企旗下网易云信的理论使用,并提供了节流提效的最佳实际。咱们将首先介绍 Mobile DevOps 工作中的挑战,再介绍 Proxmox 的实际,最初联合挪动利用研发 CI/CD 继续集成、继续交付给出具体的成果。 什么是 Mobile DevOps?当今 DevOps 应该为很多后盾服务端研发所熟知,从字面意思上讲,他是开发+经营的合体,实际上他是一个优良的软件交付理念,以减速软件研发交付一整套工作流程为指标,不断改进,继续翻新。因而这套理念也经常跟麻利的工作文化分割起来,能够说麻利离不开 DevOps,DevOps 是麻利理念的实际。 挪动利用开发畛域与服务端开发有显著的不同,但在 DevOps 上的理念、指标是统一的,通用的。Mobile DevOps 就是以减速挪动应用领域的研发交付流程为指标,尽快响应市场瞬息万变的需要的一套实际办法。在2020年,能够毫不客气的说,如果要想在强烈的市场竞争中怀才不遇,那么 Mobile DevOps 就是必备选项。 Mobile DevOps 的现状与挑战Mobile DevOps 的实现存在一些挑战,因为挪动端和服务端场景的差别,导致 Mobile DevOps 在实现上与服务端 DevOps 会有所不同,次要因为以下几点起因: 挪动端构建人造碎片化重大iOS App 的所有编译都依赖 MacOS 零碎的电脑:Mac Mini / Mac Pro,形状大小不一,通常购买超过10台后就须要自建 Mac 机房,对可维护性、稳定性都是一个微小的挑战。 Android App 依赖的工具链通用性较强,能够应用便宜的 PC (Win/Linux)来满足要求,依赖较多不同版本的 Android SDK,NDK,Gradle 反对。 Mac App 编译依赖不同操作系统版本,有的团队对 Xcode 版本也有特定的要求。 ...

January 7, 2021 · 2 min · jiezi

关于devops:送你一份迷你书全面了解如何做好大促技术备战

云妹导读: 《京东大促的另一个战场——揭秘亿级流量背地的技术基石》迷你书正式公布!对互联网公司而言,618 、11.11 早已成为一年中最重要的两个大促节日。但一直攀升的成交额,暴涨的流量、屡翻新高的下单量,都为业务架构带来了微小冲击,想晓得京东是如何解决大促带来的挑战吗?快来看首度公开的京东 11.11 大促技术备战迷你书~ 京东在长期的大促备战和技术支持中,曾经积攒起丰盛的教训。作为京东的技术基石——京东智联云联结 InfoQ 重磅公布迷你书《京东大促的另一个战场——揭秘亿级流量背地的技术基石》,通过京东智联云大促备战攻略、技术实际与技术赋能,带你理解在大型线上流动中如何利用 DevOps 疾速定位和解决问题、平安进攻体系建设、数据存储与剖析的抉择、AI 赋能等层面的技术实际能力,面向开发者提供一份大促技术指南。 对程序员来讲,面对 618、11.11 这样级别的流动,技术难度有多大? 咱们能够看一组数据: 在往年的京东 11.11 寰球酷爱季大促中,累计下单金额超 2715 亿元。随之而来的, 京东拜访带宽较往年 618 同比晋升 20% ;拜访峰值 QPS 较往年 618 同比晋升 258% ;云平安核心自动识别 /拦挡各类攻打 69+亿次。 在这个过程中,京东智联云作为京东的技术基石,起到了极其重要的保障作用。自从 2016 年开始,京东智联云逐渐开始发力,京东团体的业务也开始一直迁徙上云。现在,批发、物流等外围业务都曾经部署到京东智联云上,大促期间须要的资源全都能够在云上按需获取, 全团体资源也都能够轻松实现弹性可伸缩。有了云的技术加持,大促的筹备工作变得更加轻松。 每一次大促都是一系列简单的工作,京东各个技术团队在屡次的大促备战工作中,积攒了丰盛的教训。从备战筹备到资源调度,从服务器、存储、网络到数据库、监控和运维,从研发效力度量到 AI 技术加持,京东全线技术都在大促中一直锻炼、一直成长,使得京东技术能够更加从容地应答每一次大促。 通过本书咱们将这些成功经验分享进去,心愿帮忙更多中国互联网行业的同仁们在各种大促流动中抗住每一次流量洪峰,为企业业务提供稳固的技术基石。技术的价值不仅仅是撑持和提高效率,用户会从技术的提高中取得齐全不同的购物体验,他的购物门路会缩短, 转化率会晋升,用户和企业都会因为技术的提高播种新的价值。而这种发明价值的能力会让技术在企业中表演更为重要的角色,也让技术人成为描述将来的艺术家。 精彩领先看 备战攻略 2692 亿狂欢背地 只需这 8 步就可做好大促备战京东智联云 DevOps 如何疾速发现、定位、解决问题京东千亿订单背地的纵深平安进攻体系京东智联云对象存储如何完满实现大促重保工作技术实际 媲美物理机,裸金属云主机极致性能轻松应答 11.11 大促京东智联云自研交换机应答海量拜访申请技术赋能 揭秘 11.11 监控排障利器 京东高稳固日志服务深度解析下笔如有神:京东基于营销行业的 AI 技术迷你书的内容来自各个技术团队中的一线技术大咖教训凝练所得,干货满满,不容错过~ 百闻不如一见,云妹以上所说都只是迷你书的一鳞半爪,想取得这本最全面的京东大促技术指南,请点击【链接 】 即可收费获取: 同时,欢送大家在浏览后留下你的心得体会,咱们将为参加流动的小伙伴送出暖冬好礼: ...

December 31, 2020 · 1 min · jiezi

关于devops:2020DevOps状态报告

这是Puppet报告的走过的第九个年头,本次报告基于对2400名IT、开发、信息安全行业的技术人员的调研,着重勾画了DevOps状态的两大趋势:平台模型、需要变更的治理。多年来,咱们曾经证实了DevOps实际会带来更好的绩效和组织成绩,也学习并分享了组织的倒退,以及如何更快地公布更好的软件。看到显著停顿的同时,咱们也看到大多数组织都在致力超过他们进阶的两头阶段。这些团队可能是较难扩大DevOps工作形式的开发团队、运维团队和平安团队。 然而,有些组织的确获得了胜利。他们扩大了DevOps超出最后晚期采纳团队的实际,持续在整个组织内一直倒退和改良。是什么造成了这种区别?胜利的组织施行的更深层次结构的变动。往年的DevOps考察显示能够产生优异后果的构造变动:将DevOps准则利用于软件交付和变更治理。 当组织胜利地建设了一个平台用于反对利用程序开发的模型时,就能够进步他们的变更管理效率,并实现DevOps打算的指标:更快、更高效、更容易地交付品质更好、更平安的软件。 为何是钻研平台模型和需要变更治理这两个方向呢?平台模型是相当无效地赋能利用团队的新办法。一旦正确施行,它就会起作用,后果就是更快、更无效地交付高质量的软件、满足组织的业务需要——大规模利用也同样如此。需要变更的治理是常见的拖慢软件公布速度、阻止企业实现目标的因素,高效的需要变更治理进步了组织在业务所需级别上按时、保质、平安地公布软件的能力。报告中,咱们在考察中探讨了发现的各种改革治理各种办法,并展现如何利用DevOps准则把变更治理从妨碍变成更快、更平安的软件交付的办法。 将DevOps扩大到Dev和Ops之外在任何组织中,通过软件发明价值不仅仅依赖于开发人员和运维人员之间的良好合作。简直所有相邻的业务性能最终都是软件过程的一部分,这些性能须要与技术交付团队一起倒退。麻利已经是工程师的专属财产,但当初曾经不是了。这些年来,从软件团队扩大到财务、人力资源、执行领导团队等等。咱们心愿DevOps准则和实际除了最后开始与他们单干的开发和运维团队,在其余畛域也会持续流传,比方DevSecOps、FinOps,可能还要其余咱们没见过的新的表现形式。兴许再过几年,“DevOps”这个词曾经是陈词滥调——甚至逐步隐没——因为有那么多的人和组织齐全采纳了DevOps的合作准则:沟通、小批量迭代、反馈循环、继续学习和改良。 使用外部平台团队扩大DevOps实际DevOps从根本上讲就是让人们可能彼此单干,为了独特的商业指标而奋斗。这必然包含团队应用的过程和工具,然而还须要常常进行对话来解决组织外部妨碍良好倒退的结构性问题,让工作可能自在流动和继续改良。只管DevOps的实际曾经被很好地了解和采纳了十年。在这场静止中,咱们依然看到大多数组织都在致力将DevOps扩大到多数胜利畛域之外。DevOps往往无奈进一步扩张的一个起因是,大多数企业的构造造成了激励不统一和不足责任感,这使得单干无奈推动。 DevOps演变模型 独自采纳一组实际的团队不能进一步推动DevOps 的进阶,必须进行相应的构造更改,以优化团队的工作形式。 DevOps演变模型表明,在没有团队内部的人工批准的状况下,在第4和第5阶段之前,组织不会在自助服务和平安集成方面获得停顿(第三阶段)。 第三阶段是一个要害的趋同点——信赖曾经在第一阶段和第二阶段建设了;团队取得了更多的自主权;部署不再是一场劫难。 在这一点上,团队能够扩大他们的新单干形式,逾越更多的性能边界,超过Dev和Ops。 在第3至第5阶段,咱们看到了一刀切的规定和流程的松动,其根本重点是自动化。在这些阶段,自动化曾经超过了为单个个体或团队解决部分问题的范畴,扩大到了更独特、更高的指标:为企业发明价值。 这就是扩充DevOps实际的含意: 通过受权集体和团队,依附他们的常识和教训以及自动化,能够在整个组织实现大规模优化。当初您能够集中精力打消多个交付流中的节约,并帮忙企业实现其指标。

December 31, 2020 · 1 min · jiezi

关于devops:活动推荐-中国-DevOps-社区深圳第十届-MeetUp-来啦

流动背景现如今,软件开发和运维畛域正在发生巨变,企业为了应答业务的疾速变动纷纷减速其数字化转型的步调。本次以「DevOps 转型与落地实际」为主题的技术沙龙流动由中国 DevOps 社区主办,将会邀请四位来自不同行业具备丰盛教训的演讲嘉宾,独特探讨在 DevOps 潮流下,各公司如何实现转型和落地实际 DevOps,进步研发效力。 流动工夫/地点12 月 26 日 13:00 - 18:00 腾讯大厦(非滨海大厦)2 楼多功能厅 (广东省深圳市南山区深南小道 10000 号) 流动嘉宾 董鑫武 华为云利用平台布道师 低代码编程技术与开发实战 演讲主题 《ROMA AppCube 利用魔方,将简单留给平台,让开发效率大幅晋升》 20 多年软件开发,软件设计从业教训,先后从事电信业务撑持零碎,企业级软件解决方案设计和利用开发,在智慧城市、园区等畛域具备多个我的项目成功经验 何文强 CODING 高级解决方案架构师 演讲主题 《DevOps 端到端价值流交付的设计、思考与实际》 具备一线互联网、物联网独角兽、全国股份制银行、新型智慧交通等跨行业从业经验,历任Java 开发高级工程师、DevOps 技术专家、高级研发经理等职,对微服务、麻利、DevOps、容器技术有粗浅的了解和丰盛的实际。现任 CODING 高级解决方案架构师,负责 CODING DevOps 解决方案架构设计和技术产品布道;负责 CODING 云原生技术钻研与落地实际。专一于一站式研发效力平台的建设和推广,聚焦于“以利用为核心”的云原生的落地与实际。 谢意 中国工商银行(澳门)金融科技部技术负责人 程序员/麻利教练/马拉松爱好者 演讲主题 《促成组织麻利改革》 十余年大型银行开发设计教训。先后在北京、珠海、广州、香港、澳门等地工作。关注团队成长、代码品质、效力晋升。目前致力于在企业中促成麻利实际和转型、DevOps 落地,受到宽泛好评。 高俊宁 某世界 500 强金融企业麻利教练 中国 DevOps 社区广州地区外围组织者 演讲主题 《数字化转型中的教练魔力》 先后任职于金融、教育和互联网金融等畛域的科技公司,15 年软件行业教训,麻利 DevOps 的忠诚拥趸,近年次要负责企业和部门的麻利转型和麻利落地工作。 ...

December 24, 2020 · 1 min · jiezi

关于devops:打开数智化之门一字之差带来的思考

20年已至岁末,数字化倒退热火朝天,产业数智化过程已势不可挡,数据量激增给传统企业带来前所未有的时机,也带来了“苦涩的懊恼”,如何让数据变成战斗力?如何让数字化倒退更上一层楼?是泛滥传统企业数智化降级过程中,亟待解决的问题。 数智化代表着什么?工业4.0,中国制作2025,新基建等无不在召唤着传统产业的数智降级。换个角度来看,传统行业的倒退也的确面临瓶颈,线下业务转线上在往年显得更加急迫,诸多传统畛域须要数智赋能以打出差异化劣势。数智化,是将来,亦是新生。 为了帮忙大家抓住把握数智化红利,把握技术倒退潮流,12月26日,京东智联云技术沙龙《产业数智化转型落地实际》行将开启,此次流动将会深刻解说线上会议打造、传统行业转型、智能车联网以及DevOps转型等开发者关注的诸多技术干货内容,以实在教训和落地案例率领开发者适应数智化转型潮流。 流动工夫:12月26日  13:00-17:30 流动地点:北京市海淀区中关村守业大巷12号楼5层多功能厅 流动日程 13:00-13:30 流动签到13:30-14:15 构建高效协同智能供应链平台,商砼行业转型之路14:15-15:00 从线下走向线上,全球性会展的数字技术驱动降级15:00-15:15 短休&茶歇15:15-16:00 企业DevOps转型,难点冲破与落地实际16:00-16:45 基于智能车联网,多场景智能出行生存构建16:45-17:15 互动&交换议题介绍 议题一 构建高效协同智能供应链平台,商砼行业转型之路 讲师简介: 许俊恺,京东智联云人工智能平台部高级产品经理,2017年退出京东AI,长期从事智能供应链产品计划的在各行业的落地工作,先后作为主产品落地多个我的项目,实现商砼、煤炭以及鞋服等等3个行业的深刻调研;2020年作为主产品推动商砼之家智能供应链我的项目,实现从产品方案设计到平台上线交付全流程的落地。 议题简介: 1、智能供应链倒退历程讲述; 2、商砼行业供应链模式以及外围痛点问题分析; 3、产业互联网的外围及协同模式分析; 4、商砼之家平台构建实例解说。 听众受害: 1、通过对于商砼行业的供应链模式分析,理解建筑行业整体供应链特点和痛点; 2、从供应链痛点动手,理解产业互联网的外围,协同的理念; 3、从落地实例剖析,智能供应链产品如何驱动产业互联网倒退。 议题二 从线下走向线上,全球性会展的数字技术驱动降级 讲师介绍: 侯超,京东智联云云产品研发部总监。在ToB行业深耕多年,专一产品计划研发,在京东曾先后负责电商云、商业化、会展云等诸多产品负责人。 议题简介: 1、受疫情影响,线下会展行业面临诸多挑战,同时也不乏翻新时机; 2、会展从线下迁徙到线上后,围绕“展、论、洽”三大会展场景,如何构建全链条的会展服务线上平台; 3、以服贸会数字平台为例,本次演讲将会解析如何实现线上线下各类交融,打造沉迷式会展体验,包含在线洽谈等方面诸多性能的技术冲破与翻新。 听众受害: 1、行业少见的国际性大型线下会议的线上迁徙教训解说; 2、全链路数字化平台打造技巧解析; 3、疫情影响下,寰球风口上的技术内容,属于眼下业界刚需。 议题三 企业DevOps转型,难点冲破与落地实际 讲师介绍: 袁涛,京东智联云企业业务部解决方案架构师。先后在IBM、灵雀云等公司从事技术、售前和交付工作,长期关注企业级利用场景、麻利合作、继续交付(DevOps)、容器PaaS、云原生、云迁徙、自动化部署测试运维等畛域,负责过研发和运维过程相干的各种工作和角色。 议题简介: 1、企业在DevOps转型中遇到的问题及落地教训; 2、DevOps落地的几种状态解说; 3、我的项目与麻利双模治理方法论; 4、京东行云DevOps平台的落地实际。 听众受害: 1、理解不同行业的企业在DevOps转型中遇到的问题和落地状态; 2、理解京东在我的项目与麻利双模治理畛域的方法论及应用形式; 3、把握如何基于京东行云DevOps平台实现落地。 议题四 基于智能车联网,多场景智能出行生存构建 讲师简介: 温子彬,京东智联云IoT产品部技术架构师。曾任京东自研音箱整体技术负责人,现为京东车联网技术负责人,专一于物联网,特地是车联网方向的技术研发工作。在物联网平台、车载小程序、场景引擎、语音交互等方面都有胜利的产品落地。 议题简介: 1、以京东服务和技术为根底,打造多场景出行生存解决方案,实现人-车-家智能生存的高品质体验,并通过产品智能化帮忙车企晋升竞争力,基于实现服务数智转型,为后市场经营找到新的业务增长点。 2、以车机中控屏为载体,联合京东智联云的自然语言了解产品、以及ASR、TTS等语音技术,实现触屏、语音、多屏的多模交互。 3、整合京东小程序的技术和车联网行业常识,搭建京东车载小程序平台,以私有化部署、SaaS服务或服务输入的形式为车企提供轻量化的服务输入。 4、以自研技术实时事件驱动框架为根底,京东场景引擎联合大数据分析、AI模型预测等能力,为用户提供功能化的服务体验。 ...

December 24, 2020 · 1 min · jiezi

关于devops:DevOps工具链在公司中扮演的关键角色

DevOps工具链是一组用于执行简单软件交付工作的数字工具。工具链中的工具通常一个接一个地执行,其中一个工具的输入是下一个工具的输出。这就是为何这些工具的标准化如此重要。最重要的是,DevOps工具链应该改善开发人员之间的合作,自动化任何必要的工作,并反对更高质量的软件,同时提供对基础设施和应用程序的可观测性。工具之间的无缝集成的确很难实现。尤其是如果你在DevOps畛域没有多年的教训。每个实例都有本人的语法和性能。解决工具之间的差距、重叠和依赖关系是一项繁琐的工作。这也被称为工具蔓延。应用大量的工具会给你的老本治理带来很大的累赘。它会耗尽你用来解决企业翻新机会的估算。 DevOps生命周期一个DevOps工具链应该涵盖DevOps过程的所有阶段,它们是: 布局与合作开发、测试和产品团队之间的沟通和合作对于更快和高质量的软件公布是至关重要的。布局为公司提供了透明度,它确保每个人都处于同一阶段。 构建打算实现后,构建应用程序的局部就开始了。这包含设计解决方案、开发代码和验证开发的代码。解决方案须要通过验收和集成测试。 C/CDCI/CD管道包含基础设施配置和自动化、配置管理和协调。自动化继续集成和交付使团队可能更频繁地获取个性。这样,他们就能更快地失去反馈,从而改良产品。 运维和监测良好的运维和监测会带来更好的事变响应。此外,它有助于剖析和识别系统中的谬误本源。这样,软件会更具弹性。 继续反馈聆听客户的意见能够帮忙推动业务的改良和翻新。相似地,剖析和整合反馈有助于更无效地公布客户真正想要和须要的个性。 内置DevOps工具链创立DevOps工具链有两种可能的办法:内置或自定义。应用内置办法,您能够应用其他人开发好的工具,并依据您的特定须要对其进行调整。应用现成的工具能够实现更好的标准化和更少的集成。往年的DevOps状态报告(下篇文章将对此报告进行解读)显示,在软件交付的平台办法方面有很大的提高。企业发现,当几个不同的团队须要实现雷同的指标——将产品交付给市场时,这是非常有必要的。平台应该为应用程序团队提供基础设施、环境、部署管道和服务。之后,团队应用该平台来构建、部署和运行应用程序。内置DevOps工具链可能工作的次要起因是它加重了开发人员的累赘。在利用程序开发和基础设施操作之间一直切换上下文会降低生产效率。因而,在平台和应用程序之间有清晰的环境能够实现更高质量的软件。 自定义DevOps工具链自定义工具集意味着须要为工具链抉择所需的工具。然而,在这里须要协调所有不同的工具来一起工作。这种办法很好,因为它使您可能应用最好的工具。应用这种办法也很难让供应商锁定。但标准化实际上并不是一个给定的个性。要创立自定义工具链,有必要让团队成员专门从事工具钻研,去考察工具之间的兼容性和依赖性匹配。如果这些工具不能很好地互相集成,那么在它们之间共享信息将是一个挑战。换句话说,团队成员应该理解他们须要治理的基础设施操作和工具。此外,自定义办法的老本也可能比内置办法更高。 论断总之,为DevOps工具链抉择工具是一个精密而及时的过程。它须要大量的钻研、测试和概念证实。与其余类型的工具不同,开发和交付工具偏向于在组织中停留更长的工夫。因而,须要审慎考虑这类工具,以适应整个团队。

December 23, 2020 · 1 min · jiezi

关于devops:干货时间聊聊DevOps下的技术系列之契约测试

摘要:本期和大家简略聊聊在服务交互场景下应用服务契约的重要性,以及契约治理的必要性,最初简略介绍了下契约测试。1、服务交互带来的问题在上一篇文章中,咱们零碎的列举了DevOps各个流程中罕用的测试技术。 接着上一篇的图,咱们简略画下一个零碎利用的外部服务的调用关系:交付一个大的零碎可能波及到多家ISV进行集成,每家ISV本人又存在前端、网关、后端等多个微服务,且各自ISV或者服务均存在本人的SE、开发和测试人员,都有本人绝对独立的版本演进,服务之间存在调用关系。 思考一下,这会带来哪些问题呢? 通过接口文档或者表格治理接口内容,服务交互单方、多方频繁对接交互调用的接口信息,频繁刷新,剪一直、理还乱,让人解体。服务依赖导致必须期待底层服务先开发实现能力联调对接和集成测试,效率低下;此时如果发现被调用服务接口不满足要求、接口缺失、接口无奈联调等问题时,须要从新期待版本联调,造成资源和工夫上的节约;服务都在不停的向前演进,调用服务与被调用服务的版本会随着内部需要减少、Bug批改、代码重构等等因素而导致接口产生变更,接口调用服务往往无奈及时获取接口变动而导致整体业务受损。2、服务契约--服务交互问题的一种解决方案如何解决服务间纷纷简单的联调问题呢?本章节咱们来聊一聊契约与契约测试。 顾明思义,契约就是一份由单方或多方独特订立的、具备强制听从性的信用文书。契约测试全称消费者驱动契约测试(Consumer Driven Contracts Testing),最早见于2011年。“消费者驱动契约测试”名称中分明形容了“契约”、“谁提供契约”的问题。 一般来说,是消费者(Consumer)把本人对输出和输入的数据结构、性能曾经并发性等冀望以约定的格局通知服务提供者(Provider),服务提供者签订批准,这就造成了一份服务契约,服务提供者对所有消费者的契约取并集进行服务能力开发,造成本人服务的对外承诺或者schema。 模型如下:生产端服务 A、B、C 调用拜访服务提供端服务A,生产端服务 A、C服务提供端服务B。服务提供端会依据生产端冀望别离生成1份契约文件,以满足生产端的诉求。 服务之间通过契约交互会带来哪些益处呢? 1)、应用契约,接口调用单方的对接、问题定界等都有“法律依据”,问题不会扯不清、道不明、来回甩锅。 2)、应用契约,就确定了交付单方的接口模式和入口与进口冀望,生产端和服务提供端能够并行开发服务,并且在开发过程中就利用契约进行预集成测试,不须要期待联调再来集成测试,大幅升高联调沟通老本。 3)、因为契约的存在,能够整体看到服务生产端的原有接口应用状况,让接口的变动有迹可循,即便变动也能够确保变动的安全性和准确性。 4)、生产端也能通过契约的变动获知服务端的API变动状况 3、契约交互的问题在第二章节咱们看到契约的根本流程。在失常的契约测试流程中,契约由消费者提供,服务者听从,依据消费者的提供的契约实现服务测试。然而,大家思考下这种模式存在什么样的问题?咱们思考下一下的问题: 单方的契约有了,然而口头协定空口无凭,契约如何存储,以及如何能力防篡改?邮件交互、会议纪要难以保护?在敏感市场,消费者提供的契约是否合乎失常诉求与合规?在多ISV服务商、多部门合作的利用零碎,消费者频繁刷新契约要求怎么办?失常须要刷新契约怎么解决、契约怎么会退或者回溯?生产端驱动,会不会造成生产端势力过大,话语权过重,倒逼服务提供端,最终也会导致整个零碎不三不四?从下面的几个问题能够看出,因为契约很重要,那么设计和管控契约也就显得更加重要。 4、契约设计与契约治理的必要性交互的问题并不像设想的那边简略,为了解决契约设计和管控的问题,咱们新增一个设计管控和契约治理的环节。 设计管控环节相似于议会这种机沟通和决策机构,用于调解和扫视契约的合理性、合规性和更改的必要性,且对于多消费者的契约做合并解决。 契约治理环节,解决契约存储、拜访认证和不可篡改性、可追溯性和可回退等问题。这样就防止了后面所说的问题,当然就义了肯定了灵活性,然而在大型零碎中,这样行为是值得的。 咱们看下,消费者的契约的生成和下载过程就变成如下流程: 同时,如果服务端要被动变更契约,也要失去生产端和扫视委员会的通过,审核通过合入后,消费者和服务提供者从契约治理平台下载契约应用。流程变得如下: 5、契约测试后面的章节,咱们花了较多篇幅介绍了契约的生成和契约在服务交互过程中的作用以及重要性,那么对契约的测试也很重要。上面咱们简略聊聊如何对契约进行测试。 契约测试不是组件测试,契约测试和外围也是通过API来进行。每个消费者只会关注本人的冀望是否失去满足,所以只须要依据本人提供的、已审核通过的契约文件进行测试。而服务提供端则须要满足所有消费者的诉求,须要拿所有消费者的契约做测试,所有契约须要测试通过。如下所示: 因为理论开发中,契约签订之后,Consumer和Provider是同步开发,所以Consumer和Provider也是别离测试。个别的契约测试过程如下: Consumer服务的测试环境,须要应用契约进行Mock Provider服务进行构建: Provider服务的测试环境,则须要依据和Consumer签订的契约文件生成的契约测试用例进行测试,通过测试契约用例验证本人提供的接口是否满足消费者须要,接口是否有变更。一旦接口产生变更,契约测试用例会执行失败。 后面所述,契约是消费者(Consumer)把本人对输出和输入的数据结构、性能曾经并发性等冀望以约定的格局通知服务提供者(Provider),服务提供者签订批准后造成的,那边契约测试的次要内容也便是这几个方面: 反对契约测试的工具有Pact、Pacto、Janus、CloudTest,Swagger也能满足局部要求。一般来说,业界应用Pact工具的较多,简略说下Pact工具的过程,具体Pact用法请参照官网: Consumer测试: Provider测试: 咱们也补充下Pact工具的优缺点 6、微服务下的服务契约样例契约个别是一个yaml文件或者json文件的格局,咱们以CSE微服务的契约为展现样例: 结语:本期和大家简略聊聊在服务交互场景下应用服务契约的重要性,曾经契约治理的必要性,最初简略介绍了下契约测试。契约测试工具用法的领导文档较多,本篇没有做开展。DevOps下,契约测试也是须要集成到流水线中,欢送下来持续交换。 本文分享自华为云社区《聊聊DevOps下的测试技术(2)聊聊契约与契约测试 》,原文作者:柳哥说 。点击关注,第一工夫理解华为云陈腐技术~

December 22, 2020 · 1 min · jiezi

关于devops:还在用ELK-是时候了解一下轻量化日志服务Loki了

一、背景在日常的零碎可视化监控过程中,当监控探知到指标异样时,咱们往往须要对问题的根因做出定位。但监控数据所裸露的信息是提前预设、高度提炼的,在信息量上存在着很大的有余,它须要联合可能承载丰盛信息的日志零碎一起应用。 当监控零碎探知到异样告警,咱们通常在Dashboard上依据异样指标所属的集群、主机、实例、利用、工夫等信息圈定问题的大抵方向,而后跳转到日志零碎做更精密的查问,获取更丰盛的信息来最终判断问题根因。 在如上流程中,监控零碎和日志零碎往往是独立的,应用形式具备很大差别。比方监控零碎Prometheus比拟受欢迎,日志零碎多采纳ES+Kibana 。他们具备齐全不同的概念、不同的搜寻语法和界面,这不仅给使用者减少了学习老本,也使得在应用时需在两套零碎中频繁做上下文切换,对问题的定位通畅。 此外,日志零碎多采纳全文索引来撑持搜寻服务,它须要为日志的原文建设反向索引,这会导致最终存储数据相较原始内容成倍增长,产生不可小觑的存储老本。并且,不论数据未来是否会被搜寻,都会在写入时因为索引操作而占用大量的计算资源,这对于日志这种写多读少的服务无疑也是一种计算资源的节约。 Loki则是为了应答上述问题而产生的解决方案,它的指标是 打造可能与监控深度集成、老本极度低廉的日志零碎。 二、Loki日志计划1,低应用老本数据模型在数据模型上Loki参考了Prometheus 。数据由 标签 、 工夫戳 、 内容 组成,所有标签雷同的数据属于同 一日志流 ,具备如下构造: 在数据模型上Loki参考了Prometheus 。数据由标签、工夫戳、内容组成,所有标签雷同的数据属于同一日志流,具备如下构造: { "stream": { "label1": "value1", "label1": "value2" }, # 标签 "values": [ ["<timestamp nanoseconds>","log content"], # 工夫戳,内容 ["<timestamp nanoseconds>","log content"] ]}标签, 形容日志所属集群、服务、主机、利用、类型等元信息, 用于前期搜寻服务;工夫戳, 日志的产生工夫;内容, 日志的原始内容。Loki还反对 多租户 ,同一租户下具备完全相同标签的日志所组成的汇合称为一个 日志流 。 在日志的采集端应用和监控时序数据统一的 标签 ,这样在能够后续与监控零碎联合时应用雷同的标签,也为在UI界面中与监控联合应用做疾速上下文切换提供数据根底。 LogQLLoki应用相似Prometheus的PromQL的查问语句logQL ,语法简略并贴近社区应用习惯,升高用户学习和应用老本。语法例子如下: {file="debug.log""} |= "err"流选择器: {label1="value1", label2="value2"}, 通过标签抉择 日志流 , 反对等、不等、匹配、不匹配等抉择形式;过滤器: |= "err",过滤日志内容,反对蕴含、不蕴含、匹配、不匹配等过滤形式。这种工作形式相似于find+grep,find找出文件,grep从文件中逐行匹配: find . -name "debug.log" | grep errlogQL除反对日志内容查问外,还反对对日志总量、频率等聚合计算。 ...

December 21, 2020 · 3 min · jiezi

关于devops:GitOps实战

简介GitOps是一种开发运维实际,其核心思想是将整个应用环境以文件模式保留在Git仓库中,并通过Git的相干工具对利用进行更新、回滚等操作。 OneDev(https://github.com/theonedev/...)是一个开源的自带继续集成和部署性能的Git仓库管理软件,和GitLab相似,但更简略,机器要求低,性能好。 这篇文章介绍应用OneDev对基于Kubernetes的利用实现GitOps。 创立Kubernetes集群首先咱们须要一个Kubernetes集群,您能够应用现成的,也能够新建一个。这里咱们应用阿里云的ACK。登录到阿里云ACK控制台,并创立费用较低的ACK托管版集群。相干选项: 集群规格:抉择较便宜的标准版即可配置SNAT:必须勾选公网拜访:必须勾选Worker配置:两个节点即可。每个节点内存至多为4G。应用默认操作系统。登录形式为简略起见抉择明码并设置组件配置:除了勾选“装置Ingress组件“,其余组件均不须要集群创立胜利后,将连贯信息里的公网拜访凭据复制到本地文件$HOME/.kube/config并运行如下命令确认可能连贯到集群(如果本地还没有kubectl,能够参照此文先进行装置): $ kubectl cluster-info 因为国内拜访官网Docker Registry太慢,咱们还须要应用阿里的容器镜像服务。拜访容器镜像服务,并在适合的命名空间内创立镜像仓库gitops-demo。为不便配置,仓库类型抉择公开。代码源抉择本地仓库。镜像仓库创立后,详情页里查看所在阿里云区域的docker registry(比方http://registry.cn-shanghai.aliyuncs.com),并确保在命令行里能用适合的用户名和明码登录该registry。 部署OneDev为不便对集群里的利用进行管制,咱们将OneDev部署到Kubernetes集群里。 1.运行上面的命令设置默认的storageclass。因为OneDev的部署须要申请贮存卷(详见下步): kubectl patch storageclass alicloud-disk-ssd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'2.下载OneDev的K8s资源定义, 解压并运行如下命令(OneDev部署会创立两个存储卷:100G的用来存储Git仓库,20G的用来存储MySQL数据库,存储卷的大小能够在文件k8s-resources/production/disk-settings.yaml中进行批改): $ cd k8s-resources/production$ kubectl apply -k .3.部署实现后,运行上面的命令获取OneDev服务的external ip(如果external ip还未调配,期待片刻后再重试): $ kubectl get services -n onedev4.在浏览器内拜访地址http://<OneDev external ip>并按提醒配置OneDev(除了创立管理员账号外,其余均用默认设置)。如果网页无法访问,期待片刻再重试。 创立示例利用接着咱们配置一个示例利用: 1.在OneDev Projects页面中创立一个名为gitops-demo的我的项目2.在命令行下运行如下命令创立一个react我的项目并push到OneDev(该步骤须要node.js运行环境,具体参照react文档: $ npx create-react-app gitops-demo $ cd gitops-demo$ git remote add origin http://<OneDev external ip>/gitops-demo$ git push --set-upstream origin master (应用之前创立的OneDev管理员作为push的账号)3.刷新OneDev示例我的项目的_Files_页面,并按下图所示点击_Add build spec_链接: 4.在build spec编辑页面中,点击Edit Source(留神之前不要减少任何Job),而后将build spec的源代码替换为如下内容: ...

December 21, 2020 · 2 min · jiezi

关于devops:50有用的DevOps工具二

原文: https://dzone.com/articles/50...翻译: 祝坤荣 5.ChefChef对于钟爱CI/CD的人们来说是个现实的抉择。其背地应用了自描述的文件,模板;一系列筹备好的模板。Cookbook可进行统一的配置让你的基础设施能够疾速扩大。所有这些都被优雅的Ruby包装成了DSL。Link: https://www.chef.io/products/chef-infra/ 6. Ansible当波及到主动运行如配置管理,利用部署,根底服务编排等可重复性工作时,Ansible是你的好帮手。不须要额定的自定义平安基础设施和agent,Ansible能够用YAML部署和运行,让你能够想写英语文本一样形容你的自动化脚本。Link: https://www.ansible.com/ 7.PuppetPuppet可能是这份清单里最古老的IAC工具,这示意在它的畛域其极其有教训和较高的成熟度,和一个蓬勃的社区。让Puppet不同凡响的是它设置IAC和自动化的形式,那就是应用Puppt,你须要定义一个申明的状态,Puppet会本人找出最好失去那个状态的形式。Link: https://puppet.com/ 继续集成与交付8.CircleCICircleCI是一个用于部署过程的综合性软件工具,其通过构建和测试自动化的形式提供将代码集成并交付到寰球的状态。Link: https://circleci.com/ 9.Harness作为第一个继续交付即服务的平台,Harness帮忙部署团队自动化他们的整个继续交付过程并提供部署失败的平安计划。 Link: https://harness.io/ 10.Buddy通过一个简略的UI/UX, Buddy作为一个智能CI/CD工具显著升高了应用DevOps的门槛。 Link: https://buddy.works/ 开发自动化11.ProbotProbot为利用创立提供一个机器人框架,其专门为GitHub优化。Probot利用很容易编写,部署和分享。 Link: https://probot.github.io/ 12.AWS OpsworksAWS Opworks是为在AWS上应用Chef自动化和Puppet企业版提供的。通过AWS Opsworks,你能够简略的自动化服务器的部署,配置和治理。 Link: https://aws.amazon.com/opsworks/ 13.Relay事件驱动架构当初也不陈腐,但Relay是专门为DevOps而设计的。Relay有大量开箱即用的集成与工作流能够用,其能够实现低价值的自动化工作,让你能够专一在团队中更重要的局部。 14.CA Automic Workload自动化这是一个CA自动化能提供的全面的智能,当你打算自动化workload负载时。 Link: Here 可用性测试15.CloudEndure提供实时,像素级的复制,确保对于数据库和利用的子复原节点更好的数据集成。复制算法不会影响零碎的性能而且甚至不须要零碎重启。 Link: https://www.cloudendure.com/ 数据库与大数据16.MySQLMySQL是一个应用简略的数据库,能够稳固,牢靠的存储大量信息,并有很多高级个性。它被行业中的公司Facebook,Paypal,Google大量应用。 Link: https://www.mysql.com/ 17. MariaDBMariaDB是MySQL的开发人员开发的开源数据库。它的使用者有维基百科,WordPress.com和Google。它是抉择疾速,可扩大与强壮服务的不错抉择。 Link: https://mariadb.org/ 18.LiquibaseLiquibase是解决数据库变更和部署治理的开源工具。它帮忙团队跟踪数据库版本,数据库schema部署和逻辑变更。 Link: https://www.liquibase.org/ 19.DatadogDatadog帮你收集所有不应用的导致程序变慢的元数据,比方慢查问,抛异样,不受控的谬误日志,缓存穿透,增长的上游服务。通过Datadog,所有这些事件,服务状态,度量数据都被收集到同一个地方病应用可视图形化的形式示意进去。 Link: https://www.datadoghq.com/ 20.DigitalOceanDigitalOcean是一个快速增长的云托管厂商。它能够秒级部署一个基于linux的虚拟机-叫‘Droplet’。Digital Ocean提供99.99%的高可用性和均匀219ms的加载工夫。 Link: https://www.digitalocean.com/ 21.M3由Uber工程团队提供,当Uber发现现有开源计划达不到他们的需要后,M3提供多年的海量度量数据。M3被设计用来最大化度量管道的每个方面,而又能够有最小化的硬件占用。 Link: https://eng.uber.com/m3/ 本文来自祝坤荣(时序)的微信公众号「麦芽面包,id「darkjune_think」转载请注明。 交换Email: zhukunrong@yeah.net微博:祝坤荣开发者/科幻爱好者/硬核主机玩家/业余翻译

December 20, 2020 · 1 min · jiezi

关于devops:Artifactory-Terrafrom-plugin来了

前言随着多云环境和DevOps遍及,越来多的DevOps工程师要面临云上与云下资源的自动化治理问题。 作为寰球当先的Artifact Managenment软件供应商,JFrog的Artifactory也被泛滥知名企业采纳,成为以后最风行的devops工具之一。那么通过什么办法可能在咱们的云环境中疾速部署一套Artifactory呢?置信大家都会立即想起另外一个出名的IaC工具terraform。 JFrog正式提供了terraform插件,能够让大家通过IaC的形式疾速部署Artifactory。 Terraform新增Artifactory插件Terraform是HashiCorp提供的基础架构即代码工具,可用于以平安,可反复的形式构建,更改和治理基础架构。 应用称为HashiCorp配置语言(HCL)的配置语言,操作员和基础架构团队能够通过易于了解的自动化部署来治理环境。 Terraform的Artifactory Provider是一个收费插件,该插件扩大了HCL以可能构建Artifactory实例。它使基础架构管理员能够通过Terraform脚本配置Artifactory信息库,权限等。 一旦可能主动实现Artifactory的配置,便能够在多个Artifactory实例或数百个Artifactory实例中牢靠地复制这些配置。 通过Terraform Provider加载Artifacotry配置能够通过将以下代码段增加到.tf文件中来在Terraform脚本中启用该插件。 required_providers申明将主动从Terraform注册表中加载插件。 terraform { required_providers { artifactory = { source = "jfrog/artifactory" version = "2.2.4" } } } variable "artifactory_url" { description = "The base URL of the Artifactory deployment" type        = string } variable "artifactory_username" { description = "The username for the Artifactory administrator" type        = string } variable "artifactory_password" { description = "The password for the Artifactory administrator" type        = string ...

December 11, 2020 · 2 min · jiezi

关于devops:十分钟认识-DevOps-与CICD

DevOpsDevOps是Development和Operations的组合,是一种方法论,是一组过程、办法与零碎的统称,用于促成利用开发、利用运维和品质保障(QA)部门之间的沟通、合作与整合。以期突破传统开发和经营之间的壁垒和鸿沟。DevOps是一种器重“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通单干的文化、静止或常规。通过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、公布软件可能更加地快捷、频繁和牢靠。具体来说,就是在软件交付和部署过程中进步沟通与合作的效率,旨在更快、更牢靠的的公布更高质量的产品。 也就是说DevOps是一组过程和办法的统称,并不指代某一特定的软件工具或软件工具组合。各种工具软件或软件组合能够实现DevOps的概念办法。其本质是一整套的方法论,而不是指某种或某些工具汇合,与软件开发中设计到的OOP、AOP、IOC(或DI)等相似,是一种实践或过程或办法的形象或代称。 CICI的英文名称是Continuous Integration,中文翻译为:继续集成。CI中,开发人员将会频繁地向骨干提交代码,这些新提交的代码在最终合并到骨干前,须要通过编译和自动化测试流进行验证。 继续集成(CI)是在源代码变更后自动检测、拉取、构建和(在大多数状况下)进行单元测试的过程。继续集成的指标是疾速确保开发人员新提交的变更是好的,并且适宜在代码库中进一步应用。CI的流程执行和实践实际让咱们能够确定新代码和原有代码是否正确地集成在一起。 CDCD可对应多个英文名称,继续交付Continuous Delivery和继续部署Continuous Deployment,一下别离介绍。 查了一些材料,对于继续交互和继续部署的概念比拟凌乱,以下的概念总结按大部分的材料总结而来。 继续交付实现 CI 中构建及单元测试和集成测试的自动化流程后,继续交付可主动将已验证的代码公布到存储库。为了实现高效的继续交付流程,务必要确保 CI 已内置于开发管道。继续交付的指标是领有一个可随时部署到生产环境的代码库。在继续交付中,每个阶段(从代码更改的合并,到生产就绪型构建版本的交付)都波及测试自动化和代码公布自动化。在流程完结时,运维团队能够疾速、轻松地将利用部署到生产环境中或公布给最终应用的用户。 继续部署对于一个成熟的CI/CD管道(Pipeline)来说,最初的阶段是继续部署。作为继续交付——主动将生产就绪型构建版本公布到代码存储库——的延长,继续部署能够主动将利用公布到生产环境。继续部署意味着所有的变更都会被主动部署到生产环境中。继续交付意味着所有的变更都能够被部署到生产环境中,然而出于业务思考,能够抉择不部署。如果要施行继续部署,必须先施行继续交付。 继续交付并不是指软件每一个改变都要尽快部署到产品环境中,它指的是任何的代码批改都能够在任何时候施行部署。 继续交付示意的是一种能力,而继续部署示意的则一种形式。继续部署是继续交付的最高阶段。 Agile Development另外一个概念,也就是所谓的麻利开发,仿佛还没有所谓的简称,而且这个称说仿佛在国内被滥用了。麻利开发着重于一种开发的思路,拥抱变动和疾速迭代。如何实现麻利开发,目前仿佛尚没有欠缺的工具链,更多的是一种概念性,调侃的说法“既想马儿跑得快,又想马儿不吃草”的另外一种说法。 上图揭示了麻利开发的一些外延和指标,仿佛有点儿一本真经的胡言乱语的意思。 CI、CD、DevOps关系概念性的内容,每个人的了解都有所不同。就好比CGI 这个词,即能够了解成CGI这种协定,也能够了解成实现了CGI协定的软件工具,都没有问题,咬文嚼字过犹不及。留下一图: 链接:https://blog.jjonline.cn/linu...

December 11, 2020 · 1 min · jiezi

关于devops:没有它你的DevOps是玩不转的你信不

摘要:架构的抉择对于DevOps的实际是至关重要的,从某种程度上来说,架构就是DevOps这场战斗的粮草,它是撑持着DevOps胜利落地的重要前提。善用兵者,役不再籍,粮不三载。取用于国,因粮于敌,故军食可足也。 ——《孙子兵法》 在现代,带兵作战的将领,不仅要能长于用兵,而且要能保障食粮的短缺。正所谓兵马未动,粮草先行。粮草永远摆在第一位,因为在冷**时代,和平中的将士都是在拼力量,吃饱才有力量打仗。 在明天互联网的“和平”环境中,咱们为了能更快的应答市场变动,始终以来一直调整着作战的方针和打法,也从传统的开发方式转变为了麻利开发,由麻利开发又过渡了到DevOps。在2019年的中国DevOps行业报告中指出:“只管受访企业冀望 DevOps 可能带来更高效的交付效率,晋升客户满意度,发明更多的商业价值,但成功实践 DevOps 仍然是一个难题 。” 其中28.22% 被调查者认为本人组织的 DevOps 实际是不胜利的, 41.13%的被调查者不分明如何掂量本人组织的 DevOps 实际是否胜利。如果以一个更加直观的数据来展现,就是在承受考察的企业中有69.35%是没有能很好的理解和实际DevOps的。 兴许,在实际DevOps的这几年来,并没有多少公司是真正晓得什么是DevOps的。DevOps只是从字面上了解的突破部门墙的一键公布的工具链吗,是否有了这个工具链就是DevOps?答案是否定的。 那么,DevOps是什么?DevOps 是集文化理念、实际和工具于一身,能够进步组织高速交付应用程序和服务的能力,与应用传统软件开发和基础设施治理流程相比,可能帮忙组织更快地倒退和改良产品。这种速度使组织可能更好地服务其客户,并在市场上更高效地参加竞争——AWS 从AWS给出的定义来看,如同也还是比拟的形象。那如果简略的来说,DevOps就是让软件过程既“快”又“稳”。 何为快和稳,这个快和稳体现在,部署频率、交付周期、均匀修复时长、变更失败比例这4个维度上。 在2018年的DevOps调查报告中基于上述4个维度,因为仅有6%达到了所规定的高性能指标,为了防止非凡起因造成数据过低,所以放宽的条件,并给出了准高性能DevOps指标。 从达成这一准高性能DevOps指标的团队剖析来看,其具体体现在三个方面:一方面是自动化、标准化、质量保证、麻利办法的实际流动上;一方面是DevOps各个阶段的对应工具上。除此以外就是,团队正在开发利用的架构上。 架构的抉择对于DevOps的实际是至关重要的,从某种程度上来说,架构就是DevOps这场战斗的粮草,它是撑持着DevOps胜利落地的重要前提。受访的准高性能DevOps指标的团队将“应用微服务框架”作为团队正在开发利用的架构上的Top1。 什么是微服务是一种软件架构格调,它是以专一于繁多责任与性能的小型性能区块 (Small Building Blocks) 为根底,利用模块化的形式组合出简单的大型应用程序,各性能区块应用与语言无关 (Language-Independent/Language agnostic) 的 API 集互相通信。 微服务的起源是由 Peter Rodgers 博士于 2005 年度云计算博览会提出的微 Web 服务 (Micro-Web-Service) 开始,Juval Löwy 则是与他有相似的前导想法,将类别变成细粒服务 (granular services),以作为Microsoft下一阶段的软件架构,其外围想法是让服务是由相似 Unix 管道的拜访形式应用,而且简单的服务背地是应用简略URI来凋谢接口,任何服务,任何细粒都能被凋谢 (exposed)。这个设计在 HP 的实验室被实现,具备扭转简单软件系统的弱小力量。 2014年,Martin Fowler与James Lewis独特提出了微服务的概念,定义了微服务是由以繁多应用程序形成的小服务,本人领有本人的行程与轻量化解决,服务依业务功能设计,以全自动的形式部署,与其余服务应用 HTTP API 通信。同时服务会应用最小的规模的集中管理 (例如Docker) 能力,服务能够用不同的编程语言与数据库等组件实现。 微服务的特点依据Martin Fowler的剖析,微服务架构有以下的一些通用个性,但并非所有微服务架构利用都必须具备所有这些个性: 通过服务实现利用的组件化(Componentizationvia Services):微服务架构中将组件定义为可被独立替换和降级的软件单元,在利用架构设计中通过将整体利用切分成可独立部署及降级的微服务形式进行组件化设计。 ...

December 10, 2020 · 1 min · jiezi

关于devops:GitOps用于基础设施自动化的DevOps

GitOps提供了一种自动化和治理基础设施的办法。它通过许多团队曾经利用的DevOps最佳实际来做到这一点,例如版本控制、代码评审和CI/CD管道。因为DevOps在进步生产率和软件品质方面的微小后劲,许多公司始终采纳DevOps。在这个过程中,咱们曾经找到了自动化软件开发生命周期的办法。然而,在基础设施设置和部署方面,它依然次要是一个手动过程。应用GitOps,团队能够自动化基础设施配置过程。这是因为能够应用申明文件将根底构造编写为代码(IaC)。咱们能够将它们存储在Git存储库中,就像存储利用程序开发代码一样。 GitOps是如何运作的?GitOps的概念最后是由Kubernetes治理公司Weaveworks提出的。所以对于GitOps的探讨次要是在Kubernetes的背景下进行的。向在容器中运行的微服务的转换带来了对编排平台的需要。基于容器的应用程序的供给和治理可能很简单,也很艰难。GitOps通过利用已在DevOps世界中验证过的技术来帮忙简化这一点。现在,这个想法在DevOps的爱好者中很风行,代表了IaC概念的降级模型。它围绕三个次要局部开展:基础设施即代码拉取申请CI/CD 基础设施即代码IaC是一种将基础设施作为申明文件(存储为代码)提供和治理的实际。通过利用IaC和版本控制团队能够优化所有的操作过程。GitOps以IaC的申明式模型为核心。这就是为什么Kubernetes是一个很好的实现示例。申明性意味着配置更多的是对预期状态的申明,而不是一组命令。例如,在Kubernetes中,您能够在清单中定义服务所需的pods数量。零碎会自行处理。工程师不须要编写可能达到所需pod编号的命令式脚本。任何合乎申明式模型的云本地软件都能够被视为代码。咱们应用AWS CloudFormation来编写AWS基础设施,这是一个申明性工具。这意味着咱们能够将基础设施自身视为代码。将所需状态申明为代码。零碎利用变更来实现自动化状态。 话虽如此,申明式模型在GitOps中并不是必须的。命令式定义的环境也能够这样做。 拉取申请GitOps概念背地的次要思维是版本控制系统是事实的惟一起源。咱们应用Git作为利用程序代码的变更管理系统。咱们还能够在基础设施代码中应用它。因而,整个申明文件集都在一个能够合作的中央。这使咱们可能应用Git的要害概念——操作更改的pull申请。在利用程序开发工作流中,咱们应用一个主分支作为公布分支。开发人员从主分支创立性能分支。开发一个特定的个性或故事,实现后创立一个pull申请,将其合并回主分支。同样的办法对于根底构造代码也很不便。在咱们将代码集成到代码基的另一个分支之前,创立一个pull request使代码可能通过一个代码审查过程。代码查看能够阻止坏代码进入测试或生产环境。这对于基础架构代码甚至更为重要。通过代码审查取得正式的批准对审计和故障排除有很大帮忙。 Git组织GitOps中的部署过程至多须要两个repo:应用程序repo和环境配置repo。第一个蕴含应用程序的源代码及其部署清单。第二个蕴含对每个环境应用申明性标准形容的整个零碎的冀望状态。您能够将您的环境形容为代码存储库中的开发、测试、生产,其中蕴含能够与该环境的特定版本一起运行的应用程序和基础设施服务。在基础设施的状况下,次要分支能够示意一个环境。咱们能够在个性分支中实现变更。而后创立一个pull request来合并主分支中的更改。通过这种形式,咱们能够实现合作,同时对谁执行了哪些更改放弃通明。这也有利于问题跟踪到本源,因为所有更改都是在Git中提交的。GitOps可用于任何基于Git的零碎,如GitHub、BitBucket或GitLab。它不依赖于任何工具或技术。 CI/CD要实现残缺的GitOps,您须要一个CI/CD管道。应用主动交付管道,每次Git存储库中产生更改时,您都能够将根底构造更改传递到指定的环境中。这里的管道用于将Git pull申请连贯到编排零碎。当您应用pull申请触发管道时,业务流程零碎将执行该工作。GitOps部署策略有两种可能:push管道和pull管道。它们之间的区别在于确保部署环境与所需的基础设施类似的形式。 Push管道许多风行的CI/CD工具都在应用这种策略。咱们将应用程序的源代码及其部署清单存储在一个存储库中。当利用程序代码中产生新的更新时,生成管道将触发。管道构建容器映像并将更改推送到环境中。这种策略带来了更大的灵活性,因为它能够反对任何类型的基础设施。毛病是它容许CI/CD工具拜访您的环境。 基于push的DevOps部署 Pull管道社区认为Pull管道办法对GitOps来说更平安的实际。通过这种办法,引入了运算符。操作符是管道和编配工具之间的一个组件。它一直地将环境存储库中的指标状态与部署基础设施中的理论状态进行比拟。操作员如果检测到任何更改,就更改根底构造以适应环境存储库。另外,还能够监督映像注册表,以确定要部署的映像的新版本。这就是GitOps如此特地的起因。 基于pull的DevOps部署 在GitOps中,只有在环境存储库中产生更改时才会进行环境更新。如果实现的基础设施以未在环境存储库中定义的任何形式更改,零碎将复原所做的任何批改。对于大多数应用程序,您可能须要多个环境。GitOps容许您创立多个能够更改环境存储库的管道。您能够在环境存储库中应用不同的分支来治理更多的环境。操作员能够通过部署到生产环境来响应一个分支的更改,也能够通过部署到测试来响应另一个分支。 GitOps的劣势何在?应用DevOps最佳实际因为GitOps是一个专一于Git工作流、IaC、CI/CD管道、不可变服务器、跟踪和可察看性等现有最佳实际的模型,它代表了Kubernetes云原生应用程序治理的更高级状态。因而,公司目前的教训和教训能够提供很多服务。 继续部署—简化继续部署意味着更快、更频繁地部署。因为不同的思考因素,如零碎的状态性、抗停机能力、上游/上游依赖关系以及许多其余组织相干流程和依赖关系,正确的继续部署始终十分具备挑战性。GitOps容许您这样做,而不用治理一堆工具,因为所有的事件都产生在版本控制系统中。因为应用了部署操作,它提供了构造和自动化。这也进步了生产率和更快的MTTD(均匀部署工夫)。自动化的继续部署确保团队每天能够公布30-100倍的更改,从而将均匀生产性能进步2-3倍。 升高均匀修复工夫(MTTR)MTTR是DevOps团队应该度量的要害指标之一。在微服务体系结构中,即便是很小的问题也很难修复。因为GitOps在版本控制系统中保留了所有更改,并且治理是自动化的,因而能够显著升高MTTR。您曾经全面理解了环境是如何变动的,并且谬误复原变得非常容易。 简化Kubernetes治理在不深刻理解Kubernetes的状况下,开发人员能够应用相熟的工具(如Git)来更轻松地解决Kubernetes的降级和个性。新的嵌入式开发人员将很容易跟上速度,并在几天内而不是几个月内沉闷起来。改良了整个公司的标准化因为GitOps有一个用于出现应用程序、软件和Kubernetes附加批改的框架,所以在整个企业中都有通明的端到端工作流。Git还能够齐全复制操作流动。 如何筹备GitOps?建设一个稳固的代码评审和测试过程。仔细检查代码更改能够指出一些显著的操作,例如增加全局变量。它能够避免坏代码被开释。而后,您能够通过pull申请提交通过验证的代码,不容许开发人员间接提交任何更改。一旦申请被检查和合并,就能够触发管道。这是保护高标准代码和随后零碎稳定性的第一步。退出GitOps意味着领有高水平的自动化,这须要对管道公布的应用程序进行彻底的测试。只管GitOps容许绝对容易地回滚,但公布通过良好测试用例的好代码会使流程更加牢靠。 重点监控GitOps容许可反复的操作过程,改良可跟踪的零碎状态、公布和回滚。认真的监督能够帮忙您辨认和避免配置中任何意外的偏移和零碎更改。所以,在开始应用GitOps之前,回顾一下你的监控技能,并增强你的监控能力,让他们可能应答这种变动。 承受文化具备长公布工夫的传统流程束缚只会妨碍您。采纳DevOps文化意味着利用最好的策略,帮忙团队了解开发和经营口头的价值。与此同时,它们必须一起合作,以创立一个整体稳固的基础设施,更快、更安稳地执行应用程序,并无效地管理系统。不足DevOps文化会障碍你享受GitOps的益处。 为什么是GitOps?GitOps是一种十分好的工作流模式,它能够帮忙你高效地解决云基础设施。GitOps能够为工程团队提供许多劣势,包含更好的协调、透明度、稳定性和零碎的耐用性。 原文链接:https://dzone.com/articles/gi...

December 10, 2020 · 1 min · jiezi

关于devops:CODING-推出独立制品仓库-WePack助力企业渐进式-DevOps-转型

在刚刚开启的 QCon 寰球软件开发大会上,CODING 发表推出全新产品——企业级制品治理平台 WePack。WePack 是 CODING 基于腾讯多年制品品质治理的能力,自主研发的制品管理工具,旨在帮忙客户逐渐替换落后的工具流程,渐进式地实现 DevOps 转型。 六成企业不足制品管理工具,亟需改善“开发软件中没有制品仓库就如同制造业中没有仓库”,在一项面向各行业头部企业的调研中,六成企业不足业余的制品管理工具,依然在应用磁盘或者构建后果进行治理。面临着不足历史追溯、失落制品信息、不足品质管控,无奈索引的难堪问题,企业迫切地心愿引入 CODING DevOps 所提供的制品管理工具。但洽购一整套 CODING DevOps,意味着替换现有整套工具链流程,落地困难重重。 在这样的市场需求下,WePack 应运而生,基于腾讯多年制品品质治理能力,经 CODING 团队打磨成型,齐全自研,可控性高。 四重伎俩,晋升制品治理能力WePack 具备以下个性帮忙企业进步制品治理能力: 1. 反对 11 种支流制品,对立治理所有制品; 2. 四层治理构造,撑持企业简单场景; 3. 反对破绽扫描及依赖剖析,升高制品品质危险; 4. 提供准确到仓库的权限管制及审计日志,提供全方位平安管控。 同时,区别于整套 CODING DevOps,WePack 可作为独自服务部署,兼容企业现有工作流,从制品库切入,实现渐进式转型。将来,还将提供制品比照,破绽库扩大,制品标准查看等能力。WePack 提供免费版及企业版两种版本,以满足不同阶段企业的不同诉求。 不负初心,与客户独特成长如大家所熟知,CODING DevOps 为企业提供了一站式 DevOps 工具平台,旨在将腾讯先进的研发治理理念产品化,服务更多客户。在这个过程中,客户一直提出问题,CODING 解决问题,WePack 就是一个典型的被客户需要催生出的产品状态。 背靠腾讯云欠缺的交付体系,目前 WePack 曾经在一些行业进行实际落地。在金融行业,WePack 的多租户能力保障了集团公司制品均可信牢靠;在游戏行业,WePack 为客户提供了寰球多地区同步、断点续传等能力。在帮忙客户解决问题的同时,也促成了 CODING 产品、团队服务能力的成长。 企业 DevOps 转型的过程是一条起伏之路,CODING 心愿能够通过提供更好的产品和服务,帮忙客户晋升研发效力,获取更大的业务收益。正如 CODING CEO 张海龙在公布中提到的那样:“心愿 WePack 能够推动云时代软件开发流程的标准化,进步数字化产品的可靠性。”凭借在开发者畛域多年的继续深耕与积淀,CODING 将在将来持续打磨 WePack,为客户带来更多价值。 ...

December 8, 2020 · 1 min · jiezi