运维

古代微信官网为了污染网络环境对于微信内营销推广把控的是十分的严格刻薄,尽管有些推广没有违规但还是被封了,转发分享链接到集体或者是群或者是发朋友圈,二心只想着推广,疏忽了微信后盾检测零碎,推广进来的链接都是被封了的,这就对之前的流量有很大影响导致推广效率升高,这也是困扰了大家很久的问题。 微信域名被封的起因:一、你的推广内容.文字.以及图片.视频带有诱导引分享比方博彩,色情,虚伪信息等。二、屡次用户举报或是被同行歹意举报。三、转发量过大,转发次数多也会触发微信检测零碎从而被封杀。 微信域名防封技巧:一、域名批量解析生成N个二级域名,域名有限替换跳转,转发进来的域名都不同,就算被举报了短时间内也不会有什么问题。二、仿举报页面就是在网页上本人做个举报按钮,不过也只能解决普通用户举报。三、多级加密跳转防封通过落地域名和入口域名的多层加密爱护原理推广落地页。通过原始推广落地页生成防封短链接，两头通过入口域名和落地域名的多层加密来爱护推广落地页。加密是技术外围，能缩小域名被封缩小流量节约。package main import ( "io/ioutil""net/http""net/url""fmt""encoding/json") func main() { //申请地址juheURL := "http://api.monkeyapi.com//初始化参数param := url.Values{}//配置申请参数,办法外部已解决urlencode问题,中文参数能够间接传参param.Set("appkey" , "appkey"); //您申请的APPKEYparam.Set("url" , "www.monkeyapi.com"); //须要查问的网站//发送申请data, err := Get(juheURL, param)if err != nil { fmt.Errorf("申请异样,错误信息:\r\n%v", err)} else { var netReturn map[string]interface{} json.Unmarshal(data, &netReturn) fmt.Println(netReturn)}} // get 网络申请func Get(apiURL string, params url.Values) (rs []byte, err error) { var Url *url.URLUrl, err = url.Parse(apiURL)if err != nil {fmt.Printf("解析url谬误:\r\n%v", err)return nil, err}//如果参数中有中文参数,这个办法会进行URLEncodeUrl.RawQuery = params.Encode()resp, err := http.Get(Url.String())if err != nil { fmt.Println("err:", err) return nil, err}defer resp.Body.Close()return ioutil.ReadAll(resp.Body)} ...

DASDAS(Direct-Attached Storage)开放系统的直连式存储曾经有近四十年的应用历史，随着用户数据的一直增长，尤其是数百GB以上时，其在备份、复原、扩大、灾备等方面的问题变得日益困扰系统管理员。直连式存储与服务器主机之间的连贯通道通常采纳SCSI连贯，随着服务器CPU的解决能力越来越强，存储硬盘空间越来越大，阵列的硬盘数量越来越多，SCSI通道将会成为IO瓶颈；服务器主机SCSI ID资源无限，可能建设的SCSI通道连贯无限。直连式存储依赖服务器主机操作系统进行数据的IO读写和存储保护治理，数据备份和复原要求占用服务器主机资源(包含CPU、零碎IO等)，数据流须要回流主机再到服务器连贯着的磁带机(库)，数据备份通常占用服务器主机资源20-30%，因而许多企业用户的日常数据备份经常在深夜或业务零碎不忙碌时进行，免得影响失常业务零碎的运行。直连式存储的数据量越大，备份和复原的工夫就越长，对服务器硬件的依赖性和影响就越大。 NASNAS（Network Attached Storage：网络从属存储）按字面简略说就是连贯在网络上，具备材料存储性能的安装，因而也称为“网络存储器”。它是一种专用数据存储服务器。它以数据为核心，将存储设备与服务器彻底拆散，集中管理数据，从而开释带宽、进步性能、升高总领有老本、爱护投资。其老本远远低于应用服务器存储，而效率却远远高于后者。NAS被定义为一种非凡的专用数据存储服务器，包含存储器件（例如磁盘阵列、CD/DVD驱动器、磁带驱动器或可挪动的存储介质）和内嵌系统软件，可提供跨平台文件共享性能。NAS通常在一个LAN上占有本人的节点，无需应用服务器的干涉，容许用户在网络上存取数据，在这种配置中，NAS集中管理和解决网络上的所有数据，将负载从利用或企业服务器上卸载下来，无效升高总领有老本，爱护用户投资。NAS自身可能反对多种协定（如NFS、CIFS、FTP、HTTP等），而且可能反对各种操作系统。通过任何一台工作站，采纳IE或[Netscape浏览器就能够对NAS设施进行直观不便的治理。NAS将存储设备连贯到现有的网络上来提供数据和文件服务。NAS服务器个别由存硬件、操作系统以及其上的文件系统等几个局部组成。NAS通过网络间接连贯磁盘贮存阵列，磁阵列具备了高容量、高效能、高牢靠等特色。NAS将存储设备通过规范的网络拓扑构造连能够无需服务器间接上网，不依赖通用的操作系统，而是采纳一个面向用户设计的，专门用于数据存储的简化操作系统，内置与网络连接所需的协定，从而使整个零碎的治理和设置较为简单。 SANSAN（Storage Area Network）即存储区域网络，采纳网状通道技术，通过FC交换机连贯存储阵列和服务器主机，建设专用于数据存储的区域网络。SAN理论是一种专门为存储建设的独立于TCP/IP网络之外的专用网络。目前个别的SAN提供目前常见的SAN有FC-SAN和IP-SAN，其中FC-SAN为通过光纤通道协定转发SCSI协定，IP-SAN通过TCP协定转发SCSI协定。 iSCSIiSCSI（Internet Small Computer System Interface，发音为/skzi/），Internet小型计算机系统接口，又称为IP-SAN，是一种基于因特网及SCSI-3协定下的存储技术。 特点：透过TCP/IP网络发送，使连贯间隔可作有限的地区延长、连贯的服务器数量有限、因为是服务器架构，因而也能够实现在线扩容以及动静部署。 性能：iSCSI利用TCP/IP中的端口860和3260作为沟通的渠道，在两部计算机之间利用iSCSI的协定来替换SCSI命令，让计算机能够透过高速的LAN集线来把SAN模仿成为本地的存储安装。具体流程为iSCSI基于利用十分宽泛的TCP/IP协定，将SCSI命令/数据块封装为iSCSI包，再封装至TCP报文，而后封装到IP报文中。iSCSI通过TCP面向连贯的协定来爱护数据块的牢靠交付。因为iSCSI基于IP协定栈，因而能够在规范以太网设施上通过路由器或交换机来传输。

如果网站被歹意攻打无法访问怎么办？服务器始终被攻打怎么办？如何能力防备服务器被攻打？服务器被攻打的常见形式有两种：一种是CC，一个是DDOS。如果是CC攻击方式，机房技术会依据攻打的类型及时调整策略，CDN的服务在策略上能够先过一层，很无效的针对CC攻打。如果是DDOS，必须要机房有硬防才能够进攻的，这个必须须要带宽短缺才能够解决的，同时CDN进行分流和荡涤等。应用服务器之前能够通过一些简略的措施来晋升服务器的平安问题，那么这些措施有哪些呢，该如何防备服务器被攻打呢？1、首先服务器肯定要把administrator禁用；2、系统升级、打操作系统补丁，尤其是IIS6.0补丁、SQLSP3a补丁，甚至IE6.0补丁也要打，同时及时跟踪最新漏洞补丁；3、启动零碎自带的Internet连贯防火墙，在设置服务选项中勾选Web服务器；4、禁止响应ICMP路由通告报文；5、禁用服务里的Workstation；6、阻止IUSR用户晋升权限；7、避免SQL注入。做好服务器的进攻措施，以防为主被攻打还是很有必要的，业还是要做好对服务器的保护措施，以防被随时歹意攻打，减小服务器被攻打带来的危害有须要也能够分割小蚁网络，24小时营销QQ：2635156190，www.xy（小蚁）3000.co

概述如果还有不理解宝塔面板怎么应用的小伙伴，能够看下前文： 宝塔面板教程（1）基于云服务器搭建宝塔面板教程最全详解宝塔面板教程（2）宝塔面板增加WordPress站点具体图文教程宝塔面板教程（3）基于宝塔面板胜利配置网站SSL平安证书宝塔面板教程（4）WordPress网站的备份与复原（宝塔面板）宝塔面板打算工作备份数据库和备份网站程序很重要！宝塔面板中能够增加打算工作，工作类型包含：Shell脚本、备份网站、备份数据库、日志切割、开释内存、拜访URL、备份目录、木马查杀、同步工夫。在宝塔面板中定时备份数据库和网站正是应用的打算工作。 备份数据库工作类型抉择“备份数据库”，指定执行的周期，以及要备份的数据库和备份到的地位。 点击“增加工作”后，工作列表中会显示所有的工作。 备份的地位能够是服务器的磁盘，也能够是FTP服务器，阿里云OSS，腾讯云COS，七牛云存储等。默认只有一个服务器磁盘，如果想备份到其余地位，须要到软件商店中装置相应的插件。 备份到其余地位 宝塔面板备份数据库和网站到阿里云OSS当增加齐备份工作后，应该手动运行一次，并查看备份包是否残缺。从工作列表中能够关上工作的日志，有备份的地位。 也能够在数据库治理中找到备份的数据库。 备份详情如下图所示： 备份网站备份网站和备份数据库的步骤是一样的，只不过工作类型抉择“备份网站” 这里不再赘述。 网站程序复原WordPress网站的备份与复原（宝塔面板） 原文地址：http://tencent.yundashi168.com/657.html

背景：DevOps曾经成为软件开发畛域一个煊赫一时的名词。麻利开发、继续交付、CI/CD，K8s…这些支流的开发理念、工具无一例外都与DevOps有着很强的分割。这种环境影响下，传统的运维团队均开始向DevOps进行转型。一时之间运维开发、SRE、工程效力工程师需求量大增，无论公司大小，都会开始着手DevOps的从0到1的建设。咱们开始搭建工具链、部署流水线、集成自动化测试工具、开发自动化公布零碎……所有的一切都是为了欠缺咱们自动化体系，从而进步开发效率，优化产品质量。 那么问题来了，你团队所建设的DevOps体系，曾经是欠缺的DevOps了么？ 注释：咱们如何去评估目前DevOps中继续交付的建设状况呢，这里笔者总结了一些咱们在DevOps初期应该进行的一些工作，这些工作大多数属于工具链的集成，咱们能够对照下述十四条关卡，来验证一下咱们的DevOps建设中继续交付这一环节是否走在了一条正确的路线上吧。 1， 版本控制 版本控制是指通过记录软件开发过程中的源代码、配置信息、环境、数据等，疾速的复原及拜访任意一个版本。版本控制最次要的性能就是追踪文件的变更。 罕用版本管理工具：git 2， 最优分支策略 分支的品种很多，大多数团队会应用到骨干分支、开发分支、长期分支、性能分支、预公布分支、bug修复分支等等。那么如何抉择一个最优分支策略，是咱们开发团队必须去标准的一件事。分支策略与版本公布频率之间有肯定的相关性，咱们要依据本人团队开发模式以及我的项目迭代周期来抉择最优的分支策略。 3， 代码动态扫描 代码动态扫描须要从上面几个维度进行查看：复杂度散布、反复代码、单元测试统计、代码规定查看、正文率、潜在BUG、构造与设计。通过在构建pipeline中加设代码动态扫描的品质关卡，确保咱们的代码能够达到一个可公布的级别。 罕用的代码动态扫描工具：如SonarQube。 4， 80%以上单元测试覆盖率 进步单元测试的意义最重要的一点是保障代码所对应的性能失常、而单元测试覆盖率的查看是以一种束缚形式来标准开发人员应用单元测试，通过设置单元测试覆盖率的关卡来保障开发代码的正确性，并让单元测试逐步地变成开发习惯。 5， 破绽扫描 每个我的项目中，高达99.9%的代码来自于内部依赖，为了防止反复造轮子，咱们援用了大量的内部开源框架及组件，这些内部依赖是否有平安，是否存在高危破绽，开发人员个别是无奈关注到的，所以咱们须要一款产品能够集成到咱们开发的IDE、设置成为构建流程pipeline中的品质关卡、无缝的对接到咱们的制品库中，来扫描咱们所有的内部依赖。 罕用破绽扫描工具：JFrog Xray 6， 制品治理 制品是构建过程的产出物。包含软件包、测试报告、利用配置文件等。制品治理是对软件研发过程中生成的产物的治理，个别作为最终交付物实现公布和交付。你所治理的制品能够统称为二进制文件，制品仓库则能够提供所有二进制文件的治理能力，提供全语言的依赖解析能力以及收集整个软件生命周期的信息与制品关联。 罕用制品治理仓库：Artifactory 7， 开源协定扫描 开源协定有上百种，宽松水平不一。是否容许商用、是否能够批改、批改后是否须要持续开源等都是每种协定特有的个性。咱们作为用户，作为开发者，为了进步开发效率，防止反复造轮子，难免会援用大量的内部组件及框架，那咱们在DevOps建设过程中则必须留神对开源协定的治理及扫描。 罕用的开源协定： l Apache 2：间接应用须保留原始许可申明，若对其进行批改，需向用户阐明。 l MIT：必须保留原始许可证申明 l BSD：必须保留原始许可证申明，局部版本不得应用原作者姓名用于软件销售 l GPL：若包涵GPL代码，整个我的项目则必须应用GPL许可证。 罕用的协定扫描工具：JFrog Xray。 8， 不可变基础设施 不可变基础设施是指任何基础设施实例在部署后永远不会被批改。如果须要以任何形式更新，修复或批改某些内容，则会应用一批新的实例去替换，并在通过验证后，将新的基础设施实例上线，替换掉旧的实例。这种在当年在物理机或虚拟机上无奈疾速实现的这种不可变基础设施的理念，随着docker的遍及正在飞快的倒退，咱们能够通过容器的形式疾速的实现。这种模式能够为咱们缩小配置管理的累赘，并使得 DevOps 更加容易实际 最佳实际形式：Docker 9， 集成测试 集成测试是在单元测试的根底上，把软件单元依照软件概要设计规格阐明的规格要求，组装成模块、子系统或零碎的过程中各局部工作是否达到或实现相应技术指标及要求。 10， 性能测试 性能测试方法是通过模仿生产运行的业务压力量和应用场景组合，来测试零碎的性能是否满足软件的性能要求。艰深地说，这种办法就是要在特定的运行条件下验证软件系统的解决能力。 11， 变更治理 在google的SRE体系中，变更治理是DevOps体系中最为重要的一个局部。依据以往的教训，90%的线上故障是因为线上变更导致的，该变更起因包含软件、硬件、环境等所有因素。建设变更管理体系目标就是为了疾速定位线上问题，止损因为变更造成的线上故障，及时告诉相干人员做好故障预防工作。所以，变更管理体系也是须要咱们重点去建设以及欠缺的。 落地形式包含但不限于下述几点： l 运维人员、对应的开发及测试人员、产品经理等微信告诉 l 大屏滚动播放最近的变更记录 l 变更记录同步到监控零碎 12， 性能开关 性能开关概念很容易了解，通过性能开关咱们能够在运行过程中对某一性能进行启动和敞开，在麻利开发模式下，为了疾速迭代，在某些团队没有齐全筹备好的状况下，咱们能够通过性能开关的形式将新性能上线并通过配置屏蔽该性能，直至所有团队准备就绪，整个性能波及到的服务全副上线后，能够关上此性能开关，提供用户应用。 ...

一、继续部署1， 现状 因为没有建设规范的继续部署流程，导致了版本管理混乱，制品管理混乱，上线持续时间长，上线测试笼罩不全面，业务流量回升后故障较多，排查简单。运维、测试、开发人员每次版本迭代的时候，都要可能须要经验一次通宵的历练，并且这种在上线的第二天仍然会呈现很多线上故障。 2， 痛点 l 自动化公布体系覆盖率低。 l 无标准化公布的流程。 a) 只重视麻利、漠视品质问题； b) 变更频繁导致故障率减少； c) 开发语言品种多，公布制品管理混乱，公布形式简单； l 平安问题容易被忽视。 二、工具介绍1， Saltstack 基于ZeroMQ的开源的配置管理工具。笔者之所以选型应用saltstack，而放弃了ansible，起因是因为ansible基于ssh通信，在管控主机超过五百台之后，基于音讯队列的命令下发形式无论在稳定性还是速度上都优于ssh协定。笔挺另外选在saltstack的起因是，在服务的开发团队中存在着不同的技术栈并行的情况，尤其是java和.net并存的状况下，saltstack对于windows的反对显著要优于ansible。更容易作为多平台的底层公布工具。 而基于SaltStack打造自动化部署平台次要是用grains、pillar、state三个个性，grains用于获取默认环境配置信息、pillar用于定义环境信息、state用于编排公布文件进行公布。 2， Artifactory 全语言制品仓库管理软件，有开源版及企业版两种。开源版反对maven制品治理；企业版反对全语言制品治理，反对元数据管理性能，提供高可用部署形式、匹配nvd及vulnDB数据库，提供破绽扫描能力。 三、针对上述痛点解决方案1， 自动化公布覆盖率低 通过搭建兼容多平台部署对立公布工具，替换掉传统的shell脚本拷贝的形式实现公布工具标准化。通过SaltStack的state个性，实现跨平台的根底服务公布、服务启停、文件公布、配置公布、近程主机治理等90%以上手动操作。应用SaltStack的state编排文件，执行近程命令，通过Artifactory获取制品及配置，将须要的版本公布到线上。 次要计划在部署平台中，通过json格局形容公布流程，通过yaml.dump(sls_json）将json文件转换成yaml各位的配置文件，最终通过平台调度saltstack执行编排好的工作。 转换后的yaml文件格式如下： 2， 标准化公布流程 l 备份 公布工作编排的第一步就是备份，备份需采纳本地备份加异地备份两种机制，本地备份用于疾速回滚，异地备份用于环境重建。 l 切流量（蓝绿部署） 对于服务，尤其是有状态的服务，须要在注册核心中进行节点下线，确保本节点所有解决完结后，再进行部署。 对于页面，须要在负载平衡上将节点登记，对没有流量的web页面进行部署操作。 l 部署 通过saltstack的sls个性，编排部署文件，对多个部署工作进行对立进行公布。 部署时咱们心愿能够在部署页面查看到相似下述信息，如：部署包对应的需要id、部署包对应代码的提交信息、部署包自动化测试的通过率、部署包的代码扫描后果、部署包的平安扫描后果、部署包人工测试的后果等等。运维人员须要在公布过程中看到此类信息，来明确包是否通过了所有品质关卡、具备了上线条件，从而判断此次上线是否能够持续进行。这里咱们应用了Artifactory的元数据性能，用于记录软件包诞生的整个生命周期的信息，并通过api形式对接到公布平台。给运维人员一个残缺的包的信息记录。 l 自动化测试 此处自动化测试次要能够了解为检测服务端口通信是否失常、回归线上性能是否可用、缺点是否被修复、新个性是否部署实现等。同时此处须要预热服务及站点，通过自动化的测试买通业务流程。 l 流量回归（金丝雀） 局部实在流量切换到曾经部署实现的利用上，通过全链路日志追踪或监控指标反馈来初步判断新上线利用是否衰弱运行，并将此后果作为后续公布或回退的根据。 l 部署补全（滚动公布） 在应用低谷工夫将流量牵引到已部署实现的利用上，同时将其余利用降级。 l 变更治理通告。 上线胜利后须要及时的告诉大家线上版本已变更，产品经理须要及时更新文档，经营人员须要及时对用户进行告知。 l 回滚 任何公布都须要思考回滚计划，对于单个利用须要回滚到一个指定版本；对于多个利用，须要明确一个回滚集，通过公布时的编排工作指定回滚的编排工作。对于数据库等更新，如果回顾简单，则须要在降级计划制订前就明确回滚计划或在业务中做好版本兼容。 3， 建设对立的制品治理仓库 大多互联网公司曾经对源码仓库有了对立的治理，但对于制品仍然处于一个原始的管理状况，比方应用ftp以及每种语言开源的治理仓库。这里遇到的问题是，运维人员须要投入大量的精力保护不同的包治理平台（如ftp、maven、nuget、pypi、docker镜像核心等）。节约掉大量运维团队的人力老本之外，也极度简单了公布流程。公布人员须要在不同的平台获取上线的包，导致公布流程凌乱，公布平台配置凌乱。并且大多数开源组件均不提供高可用能力，一旦硬件或软件呈现故障，都将重大的影响公布效率。 为了解决这种问题，咱们采纳Artifactory来治理所有语言的制品仓库。与对立gitlab一个情理，咱们把整个公司的制品对立治理，成为对接公布平台的惟一包起源，从而标准了公布流程。 4， 破绽扫描 目前平安团队扫描大多是在服务部署上线后进行，这种状况下和容易造成因为版本有安全漏洞导致的整个迭代废除，所有包须要从新编译，从新通过测试流程以及上线过程，节约掉大量的工夫，升高迭代的速度。 ...

DevOps is Hard、DevSecOps is Even Harder --- Enterprise Holdings. Enterprise Holdings. 的IT团队超过2000人，在2018年的演讲中介绍了Enterprise Holdings的DevOps是如何转型的。咱们通过打造一个不只包涵了pipeline的CI/CD平台，将其称之为SDLC。在最开始的200+个利用中，咱们挑选出5个来作为试点。过后的状况证实这次DevOps转型打算是胜利的，咱们的团队有4+位工程师和两位架构师，从2年半前就开始了整个平台的开发工作，依据业务需要确保平台能够适配各种云服务、也要适配已有的中间件，咱们也在一直对CI/CD平台进行改良，以适应所有业务场景。其的指标是让开发人员更专一于具体的我的项目开发，让工具去解决一些通用性的问题。为了达到目前的成果，咱们做了很多对于平台的需要收集及问题反馈相干的经营工作，所以在过来的一年里，咱们曾经将此套平台服务于70%的利用中，并且这个数字还在继续的减少。 在DevOps转型过程中，咱们的角色并不是软件的开发者，但咱们撑持了利用开发团队和他们所开发的利用，咱们的服务工作介于应用程序与基础设施之间。在咱们的角度来看，应用程序的开发应该是这样的： l 开发人员在本地开发 l 在仓库中查看源码 l 在构建服务器上构建利用 l 运行平安扫描 l 打包公布到JFrog的Artifactory l 公布利用到不同的环境测试 l 所有测试完结后，公布到生产环境 这个模式很简略，然而也很高效，然而为了实现这个流程做了十分多的事，咱们开发了一些被称之为共享库的模版，并将此和打包程序、自动化脚本、ansible脚本等一起存储到源码仓库中进行版本治理，同时提供给利用团队去应用。为了撑持咱们的利用团队按上述流程实际，咱们应用了很多工具。 继续集成工具链包含：git、maven、gradle、Artifactory、Bitbucket、BlackDuck、jenkins 继续交付工具包含：Ansible、jenkins、Bitbucket、Artifactory、Oracle、Tomcat等 工具应用简略，所以就会有人通知你DevOps是简略的，但这种说法是不负责任的，不能认为应用了某个工具，咱们就实际了整个DevOps理念。咱们公司的it团队由超过2000人组成，这些人开发了大量的应用程序，咱们要保障整个团队都能失常的工作。尽管每个团队应用的技术栈不同，应用的平台不同，但咱们须要找到这些人的共同点，以便在咱们的DevOps平台上更好的适配所有团队和开发者以及超过200个的利用。咱们须要保障所有人都能利用咱们的平台，并且保障平台实时可用，为此咱们在jenkins的下面应用groovy开发了很多pipeline模版、自动化脚本、jenkinsfile等供其余团队应用。这样咱们就能疏导开发人员应用工具的时候是依照咱们指引的形式去应用的，并且在这个过程中咱们设置了很多关卡，明确通知了开发人员如果进行这些校验、他们的应用程序是无奈失常的被构建的。这样的后果就是，开发人员应用咱们定义好的模版，主动进行平安扫描，收集元数据，并把利用包上传到Artifactory中对立治理。之后咱们的团队就能够通过这些元数据所收集的后果，去反查到你的应用程序包含什么。咱们在模版中保护了一个json串，通知你这个模版会做什么事、收集什么数据。 下面都是说的CI的内容，接下来咱们探讨下CD。很遗憾，到目前为止咱们依然没有方法将所有的CD流程自动化，咱们有太多的开发场景和平台，有大量简单的工作等着咱们去做。在咱们的CD体系中ansible负责了大量的工作，咱们应用jenkins去治理咱们的公布流程、并通过ansible去执行公布工作，最重要的是，咱们收集了部署中的数据（如公布的环境、公布的工夫、测试的后果等等），并把这些数据以元数据的形式回写到Artifactory中。在这个过程中你须要定制开发一些自动化的测试脚本，并把他们利用到pipeline中。 咱们的构建工作运行在一个jenkins中、测试工作运行在另一个jenkins里，这样的形式保障咱们的利用有一点点安全性。 在部署过程中咱们存在的最大的一个问题就是，每次部署不仅仅部署一个利用，可能会波及到很多利用同时公布，咱们为了解决这个问题，让利用运维团队去梳理了应用程序间的依赖关系，以及部署的程序。并且保护了一个清单来对整个公布进行阐明。Jenkins会依照这些当时定义好的清单来进行公布 ，并收集到过程中的问题、哪个stage失败、是否影响到了其余的工作等等。并把这些问题同步到pipeline中以及Artifactory的元数据上。咱们给了所有开发者对jenkins的只读权限，这样能够确保所有的相干开发者都能够看到这些问题，并及时对问题进行修复。咱们通过这种形式，把一次公布由4小时缩减到1小时。 那么接下来，咱们要保障的就是每个人都依照这个规范去执行就能够了 接下来咱们议论一些平安的话题 平安是咱们组织中十分重要的一部分，施行起来也有很多艰难。在咱们不足安全意识的时候，咱们都应用普通用户。这些普通用户，实际上领有这些流程运行的权限。应用程序的团队甚至能够随便去应用有破绽的组件，每当咱们查看到这些问题的时候，往往这些问题曾经被引入到测试环境和生产环境了，咱们须要应用到很多开源软件，然而引入这些开源软件须要破费至多一个月的工夫去评估它的平安问题是否会对咱们的应用程序带来影响，这样的流程是与麻利开发模式不合乎的。 每一天都有十分多的破绽被提交到公网上，所以咱们心愿咱们的平安问题不应该仅仅由平安团队负责，开发、测试、运维团队的所有工程师都应该对平安器重起来，所以咱们抉择把平安扫描放到咱们的CI/CD流水线里。咱们强制所有利用流水线中必须减少平安扫描，如果没有这个stage，那么这条流水线是无奈通过的。尽管开始的时候大家不违心承受，然而过了一段时间，开发人员发现平安团队找他们修复破绽的这种事变得越来越少，大家也就缓缓常态化了平安扫描这个步骤。这样平安团队也将分心的把工夫破费在钻研破绽对应用程序的影响上，缩小了与开发团队测试团队的沟通老本。另外咱们制订了流水线平安的SLA，来定义一个构建的所有依赖是否满足上线需要。在这个过程也不是齐全顺利的，咱们发现每条流水线里都进行平安扫描十分破费工夫和资源，所以咱们改良了计划，每次扫描只扫描一些新的依赖、组件以及新的破绽特色，这样也大大的进步了平安扫描的效率。 将来工作中，咱们会持续与咱们所有反对的团队放弃继续的沟通，咱们要随时理解反对的团队的所有想法和产品，结合实际状况，向他们展现咱们的CICD平台是如何给他们带来收益的，确保最终每个团队都能够采纳咱们的最佳实际，被动来接入咱们的平台。总结来说，你所晓得残缺的CI CD应该是这样的，它不仅是开发，不仅是平安，更是运维、测试。所以pipeline根本等同于所有。咱们真的想确保咱们所有的过程的设计是平安的，这是咱们团队每个人的指标，咱们真正专一于在基础设施团队外部全面整合。整合内容包含服务器环境、网络、技术栈等等，而实际上这些整合都是依赖于咱们的CICD平台建设的。 欢送观看JFrog杰蛙每周二在线课堂，点击报名： https://www.bagevent.com/even...

交换机交换机是一种用于电（光）信号转发的网络设备，它能够为接入交换机的任意两个网络节点提供独享的电信号通路。工作于OSI模型中的第二层（数据链路层），分为广域网交换机和局域网交换机。 交换机三种端口模式Access、Hybrid、TrunkAccess类型端口：只能属于1个VLAN，个别用于连贯计算机端口；Hybrid类型端口：能够容许多个VLAN通过，能够承受和发送多个VLAN报文，个别用于交换机与交换机相干的接口。Trunk类型端口：能够容许多个 VLAN通过，能够接管和发送多个VLAN报文，能够用于交换机的间接连贯也能够用于连贯用户计算机。首先，将交换机的类型进行划分，交换机分为低端(SOHO级)和高端(企业级)。　其两者的重要区别就是低端的交换机每一个物理端口为一个逻辑端口，而高端交换机则是将多个物理端口捆绑成一个逻辑端口再进行的配置的。 例如cisco网络中，交换机在局域网中最终稳固状态的接口类型次要有四种：access/trunk/ multi/ dot1q-tunnel。 1、access: 次要用来接入终端设备，如PC机、服务器、打印服务器等。 2、trunk: 次要用在连贯其它交换机，以便在线路上承载多个vlan。 3、multi: 在一个线路中承载多个vlan，但不像trunk,它不对承载的数据打标签。次要用于接入反对多vlan的服务器或者一些网络分析设施。当初根本不应用此类接口，在cisco的网络设备中，也根本不反对此类接口了。 4、dot1q-tunnel: 用在Q-in-Q隧道配置中。 什么是链路类型？ vlan的链路类型能够分为接入链路和干道链路。 1、接入链路（access link）指的交换机到用户设施的链路，即是接入到户，能够了解为由交换机向用户的链路。因为大多数电脑不能发送带vlan tag的帧，所以这段链路能够了解为不带vlan tag的链路。 2、干道链路（trunk link）指的交换机到下层设施如路由器的链路，能够了解为向广域网走的链路。这段链路因为要靠vlan来辨别用户或者服务，所以个别都带有vlan tag。 什么是端口类型？ 端口类型在以前次要分为两种，基本上用的也是access和trunk这两种端口。 1、access端口：它是交换机上用来连贯用户电脑的一种端口，只用于接入链路。例如：当一个端口属于vlan 10时，那么带着vlan 10的数据帧会被发送到交换机这个端口上，当这个数据帧通过这个端口时，vlan 10 tag 将会被剥掉，达到用户电脑时，就是一个以太网的帧。而当用户电脑发送一个以太网的帧时，通过这个端口向上走，那么这个端口就会给这个帧加上一个vlan 10 tag。而其余vlan tag的帧则不能从这个端口上下发到电脑上。 2、trunk端口：这个端口是交换机之间或者交换机和下层设施之间的通信端口，用于干道链路。一个trunk端口能够领有一个主vlan和多个副vlan，这个概念能够举个例子来了解：例如：当一个trunk端口有主vlan 10 和多个副vlan11、12、30时，带有vlan 30的数据帧能够通过这个端口，通过时vlan 30不被剥掉；当带有vlan 10的数据帧通过这个端口时也能够通过。如果一个不带vlan 的数据帧通过，那么将会被这个端口打上vlan 10 tag。这种端口的存在就是为了多个vlan的逾越交换机进行传递。 也能够看出，这两种链路形式恰好对应两种端口形式，了解起来也不算艰难。原理了解了，当看到交换机时，配置几遍就齐全明确了。 access和truck 次要是辨别VLAN中交换机的端口类型　truck端口为与其它交换机端口相连的VLAN汇聚口，access端口为交换机与VLAN域中主机相连的端口。 trunk个别是打tag标记的,个别只容许打了该tag标记的vlan 通过,所以该端口能够容许多个打tag标记的vlan 通过，而access端口个别是untag不打标记的端口,而且一个access vlan端口只容许一个access vlan通过。 access,trunk,hybid是三种端口属性　具备access性质的端口只能属于一个vlan，且该端口不打tag； ...

博卡软件于2004年在上海成立，是一家专一于为本地漂亮生存相干行业提供软件服务的_SaaS_软件提供商。次要产品是门店经营所须要的，管理软件，智能硬件以及营销小程序等。 作为一个有余30人的研发团队,并且没有真正专职的运维人员，面对快速增长的客户以及越来越多的需要，领有20多个微服务，几十个前端利用（web，小程序，app等），传统的开发和部署的形式曾经逐步成为了咱们研发团队的瓶颈,为了能高效的实现交付，咱们开始了DevOps转型之路。 因为咱们的SaaS利用齐全部署在阿里云上，通过一个偶尔的机会接触到云效后，咱们开始了应用云效+阿里云ACK代替咱们现有的Gitlab+Jenkins+ECS的CI/CD来实现DevOps。、 客户痛点 因为咱们服务的客户都是小商户为主，通常有需要或者遇到问题都不违心期待一周或者几天工夫，大多数时候都须要咱们疾速解决，并且因为咱们客户量比拟大，使得咱们必须快速反应，做到继续交付，交付周期可能是一天一次，甚至一天几次。 计划劣势 源码治理 云效的代码治理Codeup的内置评审性能，能高效的实现Code Review。内置的代码检测开箱即用，促成编码标准执行。 流水线 通过Flow流水线能够很简略的实现继续交付。Flow流水线比起Jenkins来最大的益处就是简略易用。 容器化部署 部署的最佳抉择，天然是Flow流水线的最佳搭档ACK。应用ACK后，咱们的最大收益，次要是以下3点。 节约老本。故障主动重启。主动扩容。回滚 通过Flow流水线能够回滚基本上所有部署形式。抉择阿里云ACK这种Flow的最佳搭档，则能够实现疾速零停机回滚任意版本，并且因为ACK是基于Kubernetes降级，回滚的版本不会呈现环境变动等各种其余因素造成的意外导致回滚失败。 客户反馈 SaaS公司要在竞争中拔得头筹，就须要疾速影响客户需要，同时放弃较高的稳定性。同时要疾速占领市场，就须要一直推出新产品不断创新，这个时候开发的交付效率以及低成本试错就尤为重要。通过咱们的一直尝试，最终找到了一套适宜咱们公司的高效流程和工具，那就是云效配合ACK来实现DevOps。 在DevOps上咱们也是摸着石头过河，下面分享的办法只是咱们团队当下寻找到的最佳计划，当然其中也有很多有余，咱们也在一直的摸索和改良，这篇文章分享咱们的DevOps转型过程就是心愿能够跟大家多交换，独特探讨和摸索适宜本人团队的模式。 阿里云云效：https://www.aliyun.com/produc...

掌讯信息技术有限公司创建于2009年，是一家提供企业信息化征询、创新型软件产品、电商代经营服务，标准化治理、疾速倒退的高新技术企业。以后公司正处于企业互联网市场冲破转型重要阶段，心愿将更多精力转移到业务翻新，晋升开发和交付效率，低成本试错。因而抉择一套低门槛开箱即用的继续交付、疾速部署&运维平台尤为重要。 客户痛点 · 组织、人员权限治理简单 · 好的工程实际、流程标准不容易复用，品质更无奈保障 · FTP手工公布效率慢，Jenkins须要编写大量的脚本，降本晋升效率成为了瓶颈 · 短少专职运维人员和微服务革新实战经验，研发运维效率不高 · 测试开发环境和生产环境的闲置计算资源较高 解决成果 总体上来说，掌讯信息公司在与云效&SAE共建之后，通过Codeup自动化代码查看晋升了代码品质，升高了生产的故障，FLow自动化流水线、SAE的接入岂但升高了老本，同时晋升了交付效率。 1. 降老本： · 零老本投入提高质量治理能力和继续交付能力 · 低成本高质量玩转微服务架构 2. 提效率： · SAE(Serverless利用引擎)-- 从0到1的高效体验 · 云效Codeup代码库--减速你的code review · 云效flow--高易用性，高集成性。 3. 晋升品质，缩小故障： Codeup审查代码阶段蕴含的敏感信息和依赖包破绽扫描性能岂但进步了代码品质的安全性，而且耳濡目染的进步了团队的安全意识。 客户反馈 那咱们具体是怎么做到的呢？ 第一步：云效企业级成员权限治理，做到三级平安防控 摒弃之前代码库、继续集成平台(jenkins)、品质治理平台，多平台多用户的形式，对立在阿里云平台实现用户治理。通过如下三层权限治理做到平安防控。 第二步：逐步欠缺代码质量检查，做到品质可控 开发阶段codeup代码提交(commit)主动代码查看； 测试环境部署阶段流水线(flow)增加主动代码查看环节； 生产环境部署阶段流水线(flow)公布工作执行前增加安全检查工作。 第三步：测试、正式二条自动化流水线实现继续交付 测试、正式环境流水线集成SAE(Serverless利用引擎)环境，无缝联合阿里云产品。 结语 企业翻新要做的是成长速度快于消费者需要变动的速度，所以「掌讯信息」深感依附本身摸索诚然也能够继续晋升能力，但面临的挑战要求能力的晋升也必须更快、更好。在寻求晋升开发和交付效率，低成本试错中，「掌讯信息」发现阿里通过数年互联网研发实战，曾经总结出了一套高效能的研发思维、流程及工具，那就是阿里云效+SAE。 阿里云云效：https://www.aliyun.com/produc...

一、背景在近几年，Kubernetes迅速成为了容器编排的事实上的开源规范。与虚拟机不同，Kubernetes在抽象化基础架构的同时牢靠地大规模编排容器，这能够帮忙开发人员将工作负载与基础架构的复杂性离开。Kubernetes是CI/CD自动化的现实抉择，因为它提供了许多内置性能，这些性能使应用程序部署实现标准化和可重用，进步了开发人员的生产力，并放慢了云原生应用程序的采纳。 Platform9是成立于2013年的云服务提供商，可能提供业界惟一由SaaS治理的混合云解决方案，使用户可能疾速采纳云技术并在公有部署或公共云中的任何基础架构上统一地治理VM、Kubernetes和无服务器性能。Platform9提供的Kubernetes解决方案也是业界的佼佼者。 在2019年巴塞罗那举办的KubeCon + CloudNativeCon大会上，Platform9与1000多名与会者进行了互动，有近500名与会者参加了Kubernetes的相干考察。下图列出了对于最常见的Kubernetes利用场景的调查结果： 其中，基于Kubernetes的CI/CD自动化是最为宽泛的用例，专一于帮忙开发人员更快地构建和交付应用程序。然而，在具备全自动和可反复的CI/CD流水线的生产环境中运行Kubernetes（k8s）以及继续的安全检查会带来新的挑战，包含集成的复杂性，继续的产品更新/回滚、自运维、生命周期治理等等。 解决这些挑战并没有设想中的艰难，本文将介绍Platform9如何利用JFrog的产品在Kubernetes上疾速实现CI/CD自动化并将其推广到整个组织的办法。 二、应用Artifactory和Helm的5步Kubernetes CI / CD流水线在Platform9提供的计划中，JFrog Artifactory作为微服务的Docker注册表（或多个注册表），是构建CI/CD流水线不可或缺的一部分。同时，应用Artifactory作为Helm Chart存储库，进一步使该制品治理仓库可能提供将容器部署到k8s集群所需的所有集成资源。 Artifactory还能够作为近程依赖的代理仓库，例如npm、Maven、Gradle和Go等，实现平安的Kubernetes注册表，使您可能跟踪零碎中端到端的内容、依赖关系，以及与其余Docker镜像的关系。 5步实现Kubernetes CI/CD流水线： · 步骤1.应用Artifactory中代理的注册表来开发微服务。生成的利用程序包能够是.war或.jar文件； · 步骤2.在Ubuntu上应用Tomcat和Java-8创立Docker框架作为根底镜像。将此镜像推送到Artifactory中的Docker注册表中，JFrog Xray也会对其进行扫描，以确保安全性和许可证合规性。 · 步骤3.通过将.war或.jar文件增加到Docker框架中，为微服务创立Docker镜像，将该镜像推送到Artifactory中的Docker注册表中，并通过Xray对其进行扫描。 · 步骤4.为微服务创立Helm Chart，并将其推送到Artifactory中的Helm存储库。 · 步骤5.应用Helm Chart将微服务从平安的Docker注册表部署到Kubernetes集群。 在上述流水线当中，除了负责制品仓库治理，Artifactory还能够提供品质的可审核性，因为它捕捉了整个CI/CD流程中产生的所有大量有价值的元数据，蕴含： · 构建和环境信息 · 模块的依赖关系 · CI服务器，如Jenkins，提供的相干信息 · 公布模块及其依赖的具体许可证剖析 · 公布历史信息等 应用Artifactory，能够跟踪负责生成应用程序层（例如WAR文件）的CI工作，该应用程序层是Docker镜像层的一部分。通过比拟两次构建，能够显示构建之间的差别，从而轻松跟踪哪个构建公布到了Docker镜像的哪个层，近而持续跟踪到代码的提交。 三、流水线个性解析3.1 JFrog Artifactory和Xray确保软件交付的自动化 Artifactory是一个通用的制品仓库治理平台，无论组织中的微服务在哪里运行，它都能够满足所有CI/CD的需要。Artifactory通过提供齐全的Docker兼容性，使开发人员可能将容器化的微服务部署到Kubernetes集群中。将利用程序包推送到Artifactory仓库后，您能够在开发、测试和公布阶段持续验证和降级您的容器，最初将其部署到Kubernetes中的生产集群。如之前的剖析，Artifactory还为所有利用程序包提供了残缺的可审核性和可追溯性。 JFrog Xray对Docker镜像执行深度递归扫描，并辨认所有层和依赖项中的安全漏洞。它还会查看以确保所有软件组件的许可证均合乎组织的策略。这有助于阻止易受攻击且不合规的软件投入生产。而且，Xray提供的继续扫描能力，能够确保发现新问题或更改策略时的继续安全性。 3.2 Helm Charts使CI/CD工具部署自动化 一旦您的Kubernetes基础架构启动并运行，Kubernetes Helm便使您可能通过轻松装置、更新和删除来疾速牢靠地配置容器应用程序。它为开发人员提供了一种打包应用程序并与Kubernetes社区共享的工具。它使软件供应商只需按一下按钮即可提供其容器化的应用程序。通过一个命令或单击几下鼠标，用户就能够为开发测试或生产环境装置Kubernetes应用程序。大多数风行的CI/CD工具集都能够通过Helm chart取得。 Platform9利用目录为Helm图表提供了易于拜访的按钮式部署。您能够应用App Catalog UI来抉择和部署您喜爱的CI/CD流水线工具（例如，Jenkins、Spinnaker、Artifactory、Xray等）。您能够搜寻，一键部署或配置它。 四、Platform9的托管Kubernetes服务打消了操作复杂性如果您要解决的次要业务问题，与进步开发人员的生产力，将软件更快地推向市场，以及在生产环境中运行牢靠的应用程序无关，那么您是否值得花工夫解决运维Kubernetes的麻烦和复杂性？您是否领有人员和技能来工作和运维大型Kubernetes集群？ 运维您本人的大规模Kubernetes基础架构令人生畏。谬误抉择的结果是长久的，并且会影响应用程序的可用性、性能和敏捷性。尽管在短期内外部构建解决方案可能会更便宜，但您的设计品质可能较低，或者存在一些缺点。这些缺点在您投入生产后才会意识到，从而最终会破费更多的钱。 尽管装置和治理Kubernetes不会推动业务向前倒退，但疾速为客户部署新的应用程序和版本却能够。对于开发人员，Kubernetes的最终用户，平台可用性是要害。他们不在乎是谁建造它或如何建造它的：他们只是想入手实际它，并使其运行良好。 只管开发人员不关怀集群的实现细节或其运维状态，然而依然须要有人进行运维工作以确保集群是最新、衰弱且平安的。Platform9治理您的Kubernetes环境，为您提供全自动运维，并在裸机、VMware、公共云或边缘节点上实现99.9％的SLA。这使您的DevOps团队能够腾出工夫专一于重要的事件：通过更快地构建更好的应用程序来响应客户需要。 五、总结通过上述Platform9举荐的解决方案来看，基于JFrog的Artifactory和Xray，联合Helm Chart，可能不便、快捷、清晰地搭建实用于规模化Kubernetes集群的CI/CD自动化流水线。该计划在保障利用构建和交付的疾速、平安、可反复的同时，还能为所有交付的利用提供残缺的可审核性和可追溯性。 **欢送观看JFrog杰蛙每周二在线课堂，点击报名： ...

咱们访谈了许多专业人士，以理解他们的组织在DevOps落地旅程中都有哪些的成功经验和绊脚石。 在过来的15年，咱们曾经看到 DevOps 从想法变成实际。DevOps 致力于扭转开发和经营之间的孤岛状况，以实现更快的软件交付和更高的可靠性，而且当初曾经有成千上万的组织实现胜利落地 DevOps 了。 只管 Atlassian 在这一转变中占有一席之地，但咱们仍想进一步理解当今 DevOps 的状况。往年2月，咱们对500名业余人员进行了考察，以评估他们在将DevOps引入其组织中的成功经验，所面临的阻碍以及工具和文化对其工作的影响。  咱们在调查结果中确定了三个次要趋势和一个主题。对于企业和组织来讲，落地施行 DevOps只是工夫问题，而不是要去思考是否要落地 DevOps 这个问题，但这一路上依然存在很多艰难与阻碍。 趋势1：DevOps当初是公司专业术语 与麻利在2000年代初期作为一种风行趋势开始并倒退为一种通用的工作形式相似，DevOps当初已成为支流。咱们的钻研表明，有54％的受访者属于落地施行DevOps三年以上的公司。  就像麻利帮忙组织应答一直变动的市场一样，DevOps能够帮忙公司在软件吞噬世界的同时放弃竞争力。受访者广泛示意，DevOps对他们的业务产生了踊跃影响，其中最大的收益是能够提供更高质量的可交付的成绩。有49％的受访者示意，他们转向DevOps的过程包含缩短了产品上市工夫并进步了部署频率。 DevOps还兑现了突破孤岛并促成更大协作的承诺。 在实际DevOps之后，将近一半的受访者示意与非技术团队的单干有所增加。对咱们来说，这是一个明确的信号，表明DevOps团队须要适当的工具和实际来进行研发以外的合作。  趋势2：施行DevOps可能会充斥挑战 超过80％的受访者在DevOps工作中遇到阻碍，包含从传统基础架构到企业文化的所有方面。特地是对于 DevOps 的实践者们：开发人员，IT经营，以及负责部署工具与实际的网站可靠性工程师（SRE）。 对于看起来很简略的事件，例如查看我的项目的状态，有65％的人示意他们须要应用三个或更多的工具。尽管如此，仍有四分之三的受访者更喜爱在开发工作中应用同类最佳的工具。 咱们的认识？ 问题不是工具的数量。而是这些工具没有更好的集成以及应用它们的人们没有沟通与合作。DevOps 是一种合乎逻辑的做法，三分之二的组织设定了名为“DevOps”的团队或职位形容。然而，仅将团队从新标记为“ DevOps”或增加更多工具而不采纳新的工作形式是一种已知的反模式。 除工具和职位外，还要求DevOps实践者学习新技能。因为组织朝着DevOps迈进，78%的受访者示意，这个过程中须要学习新技能，这意味着围绕CI / CD，Git和麻利等外围能力的常识至关重要。 趋势3：DevOps管理者和实践者的认识并不统一 现实与事实之间总是存在着差别。将近一半的DevOps实践者示意，他们不确定如何真正改善组织的DevOps流程。  咱们发现，实践者在落地 DevOps 的过程中最器重建设弱小的合作文化。另一方面，决策者更可能器重集体能力。此外还有一种前瞻性的思维形式，即认为敏捷性和速度是DevOps胜利的要害，而不是团队单干。 然而，当初这种差别正在消除，因为组织开始意识到实践者始终以来所把握的常识：39％的受访者示意，正确的人员和文化是DevOps胜利的首要因素，而不是工具。 理解更多报告内容 咱们心愿这些见解能引起组织和各个团队中无关如何更好地领导DevOps实际的探讨。只管总会有新的技术和工具，但从业人员（他们如何合作与工作）是高效DevOps组织的基石。  对于Atlassian来说，咱们推出了12种以上实现自动化集成的新性能，以解决咱们在调查过程中探讨的一些问题，为团队发明新的办法来对立其DevOps工作并升高合作老本。 查看钻研报告：https://bit.ly/3je5h49

一、背景在现今的社会中，每个公司都是软件公司，无论是通过台式机、云服务还是挪动设施，软件都已成为世界各地、各个公司日常工作的工具。例如，汽车是带轮子的计算机，空调是数据终端，而银行在手机中提供服务，等等。 在这个新的世界中，软件更新能够满足客户的需要。每一个交付都是您更新，或毁坏，与客户间信赖的机会。如何能力保障您的每个更新都以最快的速度提供一流的服务？ 这就是为什么DevOps对您的公司很重要。当您放慢高质量软件的交付速度时，客户会大呼过瘾，并且您能够对市场需求的变动迅速做出反馈。DevOps通过缩小在测试、评估和公布等各阶段之间，以及与相干干系人之间的摩擦，来放慢高质量软件的交付速度。辨认并解决这个过程中的痛点能够推动DevOps的胜利建设。 良好的制品仓库能够促成软件在DevOps流程中的运行。它存储了过程中所有的二进制制品（artifacts，也称为工件），同时也保留了无关它们的信息，从而缩小了不确定性，并使自动化工具可能自在、疾速地运行。 在减速软件交付的过程中通常会遇到下述的六大阻碍，而良好的制品仓库能够帮忙解决它们，以实现从代码到客户的疾速、继续的软件更新与公布。 二、阻碍一，您理解您所有的构建吗？您的开发人员团队每天都能够生成许多构建，而您能全副跟踪和把握所有的构建吗？ 如果没有全面的解决方案，那您可能会晓得哪个版本是最新的，但却无奈确认哪个版本才是最好的。您也无奈牢靠地追溯构建的历史，并把握组成该交付版本的各个局部都是来自何处。 当构建失败时，您可能辨认并回退有问题的局部吗？您如何能力查明哪些构建存在问题，以及问题呈现在构建过程中哪个地位，以便您或开发人员能够疾速提供修复。 解决方案：通用记录零碎 为您所有的构建建造一个制品核心，作为所有在DevOps流水线中运行的制品的惟一实在起源。在核心的仓库中治理和版本化所有构建的产出，意味着您能够轻松找到性能最佳、最新的构建。 制品仓库可能跟踪制品应用的地位，及其先前的所有版本，从而提供了丰盛的数据，来帮忙您追溯所有构建的起源及其先人。您能够疾速查看一个版本与另一个版本之间的差别，理解每个版本的制作形式，并找到可帮忙您修复谬误版本的参考。 三、阻碍二，您的过程中有人工操作吗？在DevOps过程中，每个须要人工染指的中央都会带来危险。例如，人工的测验会减少提早，生产环境的反复构建会带来不确定性，必须手动更改、保护和执行的用于工具治理或构建部署的脚本会浪费时间，而且容易出错。这些老本低廉的过程，任何一个都会减慢正确的软件版本公布到最终用户的速度。 解决方案：自动化和流程治理 如上一部分所讲，保存您所有构建和制品的地方制品仓库为构建治理提供了便当。但如果同时它也能够收集无关制品的信息，这将赋予您更多的能力。您对制品的理解越多，就越能实现更好的自动化，并使您的构建工具可能做出理智的决策，从而对立并减速整个部署过程中的软件交付。 您的制品仓库应该可能为您的构建工具提供丰盛的、灵便的查问和命令接口，以便它们能够不在您的干涉下主动实现工作。如果它应用规范的、平台无关的拜访机制，如REST API，则您能够任意抉择最适宜您的CI服务器。 一旦您可能实现DevOps流程的自动化，就能够更好地确保公布到生产中的每个版本都遵循雷同的流程，并且合乎通用规范。 四、阻碍三，您标准治理了所有的构建依赖吗？当初的软件应用开发的特点，一是多语言并存，二是架构在公共框架、公共库的根底之上。从而开发人员在构建过程中为这多钟开发语言和技术都拉取了大量的内部依赖，而每种语言和技术对于依赖的治理都有其本人的要求和接口。您将如何治理它们？ 这些内部资源能够随时更改，并且对其品质的管制和治理水平参差不齐，有的基本就没有保障。您如何确定每个版本中的用到了哪些依赖？如何牢靠地复用其中的某个依赖？如何检测悄悄产生的无害更新？ 而且，您的构建过程不可能跑得比拜访这些近程资源的链接快，沉重的网络负载会减慢构建速度，而拜访的中断会导致您原来牢靠的构建失败。 解决方案：依赖治理 应用本地制品仓库来代理存储内部依赖的近程资源，进而将所有内部依赖纳入对立治理。借助制品仓库对这些内部依赖的本地缓存，能够保障始终以所需的版本、最快的速度来实现构建。 更好的是，一旦您的制品仓库把握了这些内部依赖，它就能够像其余制品一样，为这些内部依赖保留和保护雷同的信息。通过跟踪依赖的历史记录和应用过程，就能始终确认每个构建中都采纳了哪个版本的依赖项。 五、阻碍四，您是如何在DevOps流程中传递交付版本的？许多DevOps流程中，在测试、验证和公布的每个阶段，都须要基于全副或局部源代码进行从新构建。这就导致每个新版本都须要破费更多的工夫，并且可能须要每个干系人进行手动评估和触发。更糟的是，随着开发人员继续地更改共享代码，每次从新构建都会带来不确定性，不得不在每个阶段反复雷同的质量检查。 一旦某个构建通过了以后查看，您如何将其理论推动到下一阶段？手动将该构建推送到下一阶段的过程很容易出错。而且，您还须要一种在整个DevOps过程中向整个团队传播该构建状态的办法。 解决方案：元数据和降级治理 如阻碍二的解决方案中所述，本地制品仓库不仅治理了所有构建及其制品，还治理了制品相干的信息，也可称为制品的元数据。这些元数据能够帮忙您对该制品的品质进行测验，起源进行跟踪。 在DevOps流程中，各个阶段之间交付版本的推动，举荐的最佳实际是防止反复构建，而是采纳制品降级的形式。也就是说，在前一个阶段实现质量检查后，制品带着其元数据，一起降级到下一个阶段。下一个阶段首先依据元数据对该制品进行质量检查和评测，确认达到质量标准再开始本阶段的工作。 降级的形式，使得每个阶段都间接基于制品发展工作，防止反复构建，在晋升效率的同时，也升高了不确定性的危险。同时，针对元数据的检测，既保证了制品在各个阶段的一致性，防止篡改，又有助于晋升品质检测的自动化水平，缩小人工的染指，提高效率的同时，也升高了出错危险。 六、阻碍五，您是如何满足客户一直增长的需要的？为了满足客户日益增长的需要，您须要明天多做，今天做得更多。这会减轻许多业务团队的累赘，进而可能会减慢整个开发流程。 而基础架构中的任何单点故障都可能是灾难性的。地理位置扩散的团队须要始终可能以雷同的速度取得雷同的资源，任何业务更新或容量降级造成的服务中断都会节约大量的生产工夫。 解决方案：企业级反对 企业级反对的解决方案可提供适应您的规模及成长的能力和灵活性。 能够在云平台中工作的制品仓库能够帮忙您有限地扩大存储和计算的老本。您的制品仓库能够应用的云供应商越多，您取得的控制权就越大。SaaS订阅选项可确保您的资源始终可用并且是最新的。 高可用、多活的集群配置能够确保高负载下制品仓库的响应能力。其冗余还为劫难复原提供了容错反对，并实现了零宕机的降级和保护。 反对多站点复制同步的制品仓库能够为跨地区的分布式团队提供寰球范畴内DevOps过程中资源、信息的疾速分享。 七、阻碍六，您适应变更的老本有多高？响应所有的客户意味着在多个运行零碎中应用多种语言进行开发。某个部门可能用Go为云平台编写代码，而另一个部门则可能用Java为挪动设施编写代码。然而每种语言和技术都有其本人的要求和反对的工具。 您将为DevOps应用哪种基础架构？当初，在您本人的数据中心中平安运行可能是最有意义的。而将来，您可能须要云平台的灵活性，或者将它们联合起来以取得各自的劣势。您将能够自由选择最适宜您需要的供应商，并在需要变动时灵便地进行更改。 解决方案：混合云的解决方案 反对混合云架构的制品仓库能够帮忙您的交付过程自动化，无论您应用的是哪种语言或运行于何种平台。通过REST API进行拜访，能够不便、灵便地与您曾经在应用的工具进行对接。 作为DevOps零碎的外围，您的制品仓库在云平台中的性能必须与在本地本人的服务器上的性能雷同。在任何环境间都可能轻松地降级构建、推动交付的解决方案能够无效地帮忙您在功能强大的混合云中实现DevOps。对所有次要提供商（例如AWS、Google Cloud、Azure、阿里云等）的集成反对，能够帮忙您实现防止供应商绑定的多云策略。 您也应该可能自主地抉择付款形式。您须要的解决方案应该是，无论您抉择固定的许可费用还是灵便的SaaS订阅，都可能帮忙您自在地构建当初和未来应用的零碎。 八、总结功能齐全的制品仓库将帮忙您实现自动化的软件交付流程，并反对您采纳新的工作形式。它能够为您提供对流程的管制和洞察力，从而能够解决呈现的问题并不断改进您的办法。通过持重的设计后，您的制品仓库能够灵便地适应企业的非凡需要。 同样重要的是，您须要一个能够在您的DevOps建设过程中成为良好合作伙伴的解决方案提供商。他们应该理解不同的办法和行业趋势。 JFrog的Artifactory制品仓库是端到端DevOps平台的外围，用于自动化治理、爱护、散发和监督所有类型的制品。Artifactory失去了近6000家客户的信赖，其中包含了世界500强中93％的客户。亚马逊、Facebook、谷歌、华为、VMware等世界顶级品牌都依附JFrog来治理其制品，推动其DevOps过程。 心愿Artifactory同样可能帮忙您解决上述的六大阻碍，胜利建设DevOps体系，实现高质量、疾速、继续的软件公布流程。 **欢送观看JFrog杰蛙每周二在线课堂，点击报名：https://www.bagevent.com/even...**

一、背景在当下的软件应用开发畛域中，越来越多的麻利化企业心愿本人的软件开发过程能以超音速、甚至于星际穿梭的速度，来疾速响应各种变动，但同时还要保障安全性。DevOps流水线无疑为这一指标提供了最佳实际。 然而，要齐全满足这样的需要，咱们应该如何去建设适合的DevOps流水线呢？有没有一种很好的形式，可能帮忙咱们去了解DevOps流水线当中CI/CD过程，以及容器技术，如Docker和Kubernetes，在其中的角色和影响呢？ 其实，DevOps流水线的建设能够类比为两种模式：火箭式或飞机式。从泛滥客户的利用实际来看，要想运行一个欠缺的、牢靠的DevOps流水线，火箭式的建设是远远不够的，理论遇到的艰难要大得多。 二、火箭发射模式咱们通常把DevOps流水线了解为一个简略的、从左到右的线性过程：编写代码、提交、构建、测试、部署，以及作为产品公布。创立进去的软件在流水线当中就像被装船运送一样，有着清晰定义的去向。 在这种模式下，创立一个应用程序就像发射登陆火星的火箭一样。在容许登陆工作持续进行之前，必须要打算、审批、测试，以及验证所有的工作。为了筹备发射，所有团队必须严密地协同工作。咱们只有一次机会去发射这个火箭，而且火箭一旦发射，就再没有机会进行批改和更新。从发射台到最终达到火星，火箭的性能是固定的、不可批改的。 火箭发射是一次性的。每一次测试都须要创立一个新的火箭，而这会带来一些未知的危险。新的火箭须要在确认所有零碎都筹备好了之后能力发射，以实现承当的工作。 这是一个清晰的、经典的工程模型。然而，这不是DevOps应有的工作形式。 三、航班运行模式上述火箭模式中比拟好的DevOps实际是在创立和运行服务时，开发和运维团队在研发生命周期的各个阶段都严密地单干。 然而，DevOps并不是像高风险火箭发射那样简略的从左到右的线性过程。相同，它是一个频繁触发且不会终止的循环过程，而且每一次触发都会引入一些新的的危险。所以，DevOps更像是古代的航空零碎。在任何工夫，寰球的航空公司都频繁地，事实上是间断地，发送着航班，运载着上百万对其充斥信赖的旅客。 航空公司治理其飞机和航线的流程，和DevOps流水线保障利用公布时效性和可靠性的办法是非常相像的。和软件企业一样，航空公司一样要紧跟技术的倒退、疾速响应平安问题，以及适应客户需要的变动，同时还要保障整个零碎不中断地运行。在日常经营中，航空公司继续对每架飞机进行查看（测试）、保护（打补丁），以及安顿经营工夫。这个过程和DevOps中利用的继续集成、更新和交付过程十分相似的。 和火箭发射的一次性不同，飞机可能重复地执行腾飞和降落，最终执行航线工作的和最后通过测试航行的都是同一架飞机，这充沛表明了两种模式的差异性。那么，怎样才能保障DevOps流水线运行得更像是一个航空公司，而不是一名火箭兵呢？ 四、起飞前的清理工作火箭和飞机都是由许多资源组成的产品，不同的生产部门别离负责构造、机械和控制系统等各个局部，而且是由不同的供应商提供大部分的组件，从最根本的如门锁、座椅、地毯等，直到简单的如导航系统等。 相似的，每一个软件应用也是由组织内的多个团队独特创立的，而且利用运行的大部分代码，例如操作系统和语言框架等，都是以企业内部的近程仓库为起源的。 开发人员能够管制将本人开发代码的哪些局部退出构建。然而，对于从公共仓库下载的内部依赖包，如npm或maven等，又该如何管制呢？那些包可能会不定期的进行批改，而这是你无法控制的。 如果你的DevOps流水线像发射火箭一样，那么针对测试或公布的每次新构建，都会成为偷渡者潜入火箭的机会。如果无奈做到继续监控，那些打算之外的货色就可能进入新的构建，从而导致每次构建都不能取得完全相同的后果。 五、返回跑道Docker镜像就像是飞行器，不论是火箭还是飞机，通过构建而成，并封装了利用要执行的所有性能。从发射到着陆，Docker镜像的能力放弃不变。 Docker引擎，联合镜像仓库，把镜像转换为容器，就像把这些飞行器推送到发射平台。而像Kubernetes这样的编排工具就进一步把这些容器发射到航线下来。 Docker引擎，联合镜像仓库，把镜像转换为容器，就像把这些飞行器推送到发射平台。而像Kubernetes这样的编排工具就进一步把这些容器发射到航线下来。 如果像解决火箭一样，每次发射一个新的，那在开发、测试，或公布阶段构建的每个Docker镜像，都有可能和前一个有一些不同。 而如果像飞机一样解决，就意味着对发射到地面的内容有更大的确定性。航空公司不会为每次腾飞都制作一架新的飞机。他们只是测试飞机，而后在航线上牢靠地运行飞机，直到飞机须要更换为止。 构建一个Docker镜像，而后在测试到公布的流水线上进行降级，而不是从新构建，可能确保这个镜像带上航线的都能每次、准时、平安地翱翔。 六、高空管制正如上述剖析的，真正的DevOps流水线不是简略的从左到右的线性过程，而是设计、合成和重构的简单、迭代、网络化的过程。 为了使DevOps流水线运行得更像是航空公司，Artifactory能够作为地勤人员，来保障所有都按计划、安稳地运行。Artifactory使得开发人员可能管制从代码构建而来的Docker镜像，并通过总是在航线中运行同一架飞机来保障可靠性和速度。 首先，Artifactory解决了一个开发人员面对的要害挑战，那就是利用如npm或maven这样的内部依赖，也能进行长久、确定的构建。利用Artifactory，开发人员可能保护内部仓库的本地缓存，从而保障内部代码的变动在没有确认可用之前不会被引入到构建当中。而且，保障内部依赖的本地拜访，也能帮忙减速构建，晋升生产力。 利用Artifactory作为Docker镜像核心，能够使得DevOps流水线中从测试到公布的各个阶段之间降级实不可变的构建产出变得更加容易，而不须要每次都从新构建。同样能够依据须要，利用Artifactory为每次构建存储的详尽信息，来创立新的确定性的构建。 飞机航行须要燃料，而航空公司，就像所有现代化企业一样，基于数据进行运维。航空公司对他们的飞机、客户和工作人员理解得越多，就越能帮忙他们最大限度地进步投资回报率。 Artifactory作为Kubernetes的Docker镜像核心，能够提供简化、平安施行运维工作所需的数据。除了容器、镜像的列表之外，Artifactory还能够可视化地展现容器里都有什么，以及这些内容是如何进入容器的。 如果再减少利用JFrog Xray对镜像进行扫描，就能够取得更多无关镜像当中代码实在安全性的信息，进一步爱护企业和利用。 七、翱翔天空不仅仅像本文说的，真正的DevOps流水线就像是现代化的航空公司，DevOps已成为大多数航空公司本身经营的要害实际。联合航空公司、西南航空公司、阿拉斯加航空公司和捷蓝航空公司就是泛滥航空公司的代表，它们曾经为DevOps和CI/CD做了大量的投资，在网络和挪动平台上为其客户提供购票、值机、登机等各种服务。这些航空公司很多都引入了Artifactory，取得了在寰球范畴倒退DevOps的微小收益。 正如这些高风险企业所展现的，仅仅将Docker容器推上跑道，对于真正的DevOps是不够的，须要利用Artifactory为CI/CD提供的反对，来确保它们在天空中平安地翱翔。 欢送观看JFrog杰蛙每周二在线课堂，点击报名： https://www.bagevent.com/even...

一、背景==== 制品，artifact，也称为工件，是指在构建或继续集成过程中从源码创立而成的二进制包，而这些二进制包通常是通过赋予其的版本号来惟一定位和治理的。制品仓库，artifact repository，则是存储和治理这些版本化的二进制包，并对外提供检索和拜访办法的应用程序。 制品仓库通常分为地方仓库、企业仓库和本地仓库。地方仓库面向公众凋谢，存储和治理事后构建好的二进制包，通常提供软件开发的各种公共框架和通用工具库，如面向Java的Maven地方仓库，面向Docker镜像的DockerHub等。企业仓库则通常位于企业或团队外部，一是缓存并对立治理地方仓库的公共制品供外部应用，以晋升拜访效率并增强监管，二是用于存储和治理企业或团队本身创立而成的各种制品，包含最终交付的利用，或者企业或团队外部应用的公共库等。本地仓库则是构建零碎的缓存，记录构建过程中所需及创立的各种制品，并与地方仓库或企业仓库交互，实现制品在不同仓库之间的传递。 在以后的DevOps体系当中，企业制品仓库已成为其中的一个重要环节，除了存储和治理制品之外，还须要和继续集成、自动测试、继续部署，以及治理、审批等各种零碎进行对接和协同，实现信息的集成、共享和流转，从而实现流水线式的继续交付。此外，企业制品仓库也是企业信息安全治理中的重要节点，只有通过平安审计的制品才可能被纳入到企业制品仓库，以实现企业继续交付流水线当中的受信源。 目前世界500强中93%的企业，寰球共有5000家以上的企业都曾经放弃了Sonatype的Nexus而应用JFrog的计划。 为什么会是这样？本文依据二者最新的倒退状况，从制品治理的各个角度列出二者的技术现状加以比拟，置信大家可能清晰地失去论断。 二、制品治理的概览比拟=========== 首先，本文从作为企业制品仓库所需的次要技术要求对二者做一个概览的比拟： 从中能够看出，JFrog的产品反对的语言包类型更为丰盛，高可用、定制化扩大，以及元数据等技术计划更为齐备，而且提供了Sonatype工具所不具备的复制同步能力，可能更好的反对跨地区的团队协同。 咱们再从更细节一些的技术点对二者进行比拟，如下图所示： 从中能够看出，JFrog可能反对代理更多类型的地方制品仓库，并且可能提供Docker镜像的分层展现。另外，在制品存储、加强查问等方面，JFrog也提供了更多的反对。 所以，仅从概览来看，JFrog无疑比Sonatype具备更为丰盛和全面的能力。 三、制品治理的计划比拟=========== 第二局部对JFrog和Sonatype的产品特点进行了概览的比拟，本节将从二者的计划特点进行更为全面的剖析。 首先来看二者的商业模式，如下图所示： JFrog提供了更为灵便自主的试用形式：在本地化部署的根底上，也提供了对于云端和混合云架构的反对，可能适应客户不同的基础架构需要；而且，具备大规模的可扩展性，可能帮忙客户节省成本。 再从部署形式来看，如下图：JFrog提供了丰盛、全面、自动化的部署形式，包含面向Kubernetes环境的Helm Chart编排，不便了产品的部署利用。 再来看可扩展性，如下图： 能够看出，JFrog可能全面反对企业级利用的扩大需要，并保障其稳定性。 以后的开发环境更多的是团队合作形式，从而要求制品仓库也可能反对跨数据中心、跨城市，甚至跨国的协同工作。二者在团队协同方面的特点如下图所示： 很显著，JFrog面向多团队、跨地区的协同工作提供了丰盛、全面的解决方案，而Sonatype只能反对单数据中心的利用模式。 在以后的DevOps体系当中，制品仓库须要可能与继续交付工具链中的其余零碎很好的集成与对接，而从这一角度来看，二者的技术特点如下图所示： JFrog全面的API笼罩、全功能的CLI工具，以及自定义的元数据等能力使得其制品仓库可能不便、全面地和客户现有的环境和工具进行集成与对接，从而不便地建设全面、统一的DevOps计划。此外，JFrog还提供了性能扩大的用户插件框架，反对定制化的二次开发。在这一方面，Sonatype只能提供无限的反对。 从最根本的制品治理的能力来看，JFrog是惟一真正的全语言反对，如下图所示： 而从制品的存储形式来看，JFrog提供了更为丰盛的解决方案，可能适应客户不同的业务需要，从而更大程度地节约老本。如下图所示：最初，从制品仓库的认证平安管理体系来看，JFrog提供了更宽泛的拜访、认证形式，以及灵便的权限体系，如下图所示： 综合下面的比拟能够看出，从作为企业制品仓库所需的各个技术层面和细节来看，JFrog的产品和计划无疑成熟度更高，可能为企业提供更为丰盛、全面、弱小且灵便的反对，而Sonatype的产品和计划只能在受限的范畴内提供反对。这也正是目前JFrog在寰球商业制品库市场占有率第一的起因所在。 四、DevSecOps的计划比拟在当下软件应用的开发过程当中，自研的外部代码所占的比例逐渐地缩小，开源的框架和共用库曾经失去了宽泛的援用。然而，开源软件的大量援用也给咱们的利用带来了安全隐患。据统计，目前14%的NPM包、30%的Docker Hub镜像都蕴含安全漏洞，而Maven包里有59%的已知安全漏洞还没有失去修复，而破绽的均匀修复工夫是290天，最重大级别破绽的均匀修复工夫也仅是265天。因而，提供针对外来制品的平安检测，构建制品受信源，已成为以后DevOps体系中对企业制品仓库的重要需要。 要想实现实现及时、精确的制品平安扫描，首先要基于精确、全面的安全漏洞数据库。JFrog和Sonatype应用的安全漏洞数据库状况如下图所示： 可见，在NVD（美国国家破绽数据库）提供的CVE（公共破绽和裸露）的根底上，JFrog还提供了VulnDB这一商业破绽数据库。而VulnDB提供了更大范畴的安全漏洞数据，如下图所示： JFrog和Sonatype的平安检测计划都能够与企业的CI/CD流水线集成。然而反对的水平还是有所不同的，如下图所示： 从上图能够看出，JFrog的计划可能笼罩更为宽泛的DevOps的链条，从而将传统的DevOps过程扩大成为DevSecOps，这也是业界以后的倒退方向。 JFrog的计划可能在DevOps的各个阶段提供安全漏洞监控方面的反对，如下图: 而且，JFrog的计划还可能将安全漏洞的监控扩大到研发或生产过程中。JFrog提供的KubeXray可能在Kubernetes的运行环境中检测并解决POD的安全漏洞问题，如下图: 而通过与IDE，如IntelliJ IDEA、Eclipse、Visual Studio等的联合，JFrog使得开发人员在开发过程中就可能时刻关注和理解利用的平安情况，从而实现平安扫描的左移。如下图： 除了发现制品的安全漏洞之外，JFrog还提供了针对安全漏洞的精准定位和影响范畴剖析的能力，使得安全漏洞的发现和修复更加精准和全面。如下图: 综上所述，JFrog是目前可能惟一提供端到端DevSecOps反对的企业制品仓库产品，除了提供最残缺的商业破绽数据库外，JFrog的产品和计划还惟一实现了安全漏洞的跨语言品种的深层次精准定位和影响范畴剖析。 五、总结企业制品仓库已成为企业建设DevOps体系的重要环节，除了根本的制品存储与治理外，还须要可能与DevOps全链条实现对接与集成，并提供安全漏洞扫描与监控，建设企业可信源，从而实现残缺的DevSecOps解决方案。 通过本文的比照和剖析能够分明地看出，JFrog的产品和解决方案无疑是更为全面、更为丰盛、更为灵便、更为弱小的抉择。 **欢送观看JFrog杰蛙每周二在线课堂，点击报名：https://www.bagevent.com/even...**

在日常运维治理的倒退过程中，可视化、自动化是一个阶段的过程必备因素，所以，对于可视化运维平台的把握与理解也十分重要，咱们运维小伙伴们也在一直的摸索与开掘当中，明天，民工哥给大家安利一款可视化的自动化运维治理平台：Spug，开源、收费，功能强大。 Spug简介Spug面向中小型企业设计的轻量级无 Agent 的自动化运维平台，整合了主机治理、主机批量执行、主机在线终端、文件在线上传下载、利用公布部署、在线工作打算、配置核心、监控、报警等一系列性能。 代码仓库地址：https://github.com/openspug/s...官网地址：https://www.spug.dev应用文档：https://www.spug.dev/docs/abo...更新日志：https://www.spug.dev/docs/cha...常见问题：https://www.spug.dev/docs/faq/Spug的性能批量执行: 主机命令在线批量执行在线终端: 主机反对浏览器在线终端登录文件治理: 主机文件在线上传下载工作打算: 灵便的在线工作打算公布部署: 反对自定义公布部署流程配置核心: 反对 KV、文本、json 等格局的配置监控核心: 反对站点、端口、过程、自定义等监控报警核心: 反对短信、邮件、钉钉、微信等报警形式优雅好看: 基于 Ant Design 的 UI 界面开源收费: 前后端代码齐全开源装置环境要求Python 3.6+Django 2.2Node 12.14React 16.11装置Spug简化所有装置操作步骤，官网也倡议应用docker进行装置，那么，接下来就应用docker来装置这款工具平台。本文操作基于Centos7.x操作系统。 1. 装置docker并启动 yum install docker -ysystemctl start docker2. 拉取镜像 阿里云的镜像与 Docker hub 同步更新，国内用户倡议应用阿里云的镜像。 $ docker pull registry.aliyuncs.com/openspug/spug3. 启动容器 Docker镜像外部应用的 Mysql 数据库。如果须要长久化存储代码和数据，能够增加：-v 映射容器内/data门路 $ docker run -d --name=spug -p 80:80 registry.aliyuncs.com/openspug/spug# 长久化存储启动命令：# mydata是本地磁盘门路，/data是容器内代码和数据初始化存储的门路$ docker run -d --name=spug -p 80:80 -v /mydata/:/data registry.aliyuncs.com/openspug/spug4. 初始化 以下操作会创立一个用户名为 admin 明码为 spug.dev 的管理员账户，可自行替换管理员账户。 $ docker exec spug init_spug admin spug.dev# 执行结束后须要重启容器$ docker restart spug5. 拜访测试 在浏览器中输出 http://localhost:80 拜访,用户名：admin  明码：spug.dev 应用介绍登录实现后，就能够看到主界面，如下 主机治理 治理保护平台可操作的主机，首次增加主机时须要输出 ssh 指定用户的明码。 批量执行 蕴含保护命令模版和批量近程执行命令两局部性能，罕用来执行一些长期的工作例如，批量装置/卸载某个依赖包等。 执行工作能够抉择一到多个在主机治理中增加的主机作为执行的指标主机，命令内容能够间接写也反对从模板中读取已保留的命令。 ...

传统研发经营模式中，平安地位绝对滞后，无奈笼罩研发阶段的平安问题。日前，《研发经营平安白皮书（2020年）》（以下简称“白皮书”）在中国信息通信研究院、中国通信标准化协会联结主办的可信云线上峰会上正式公布。该白皮书是由中国信息通信研究院牵头，联结腾讯、华为、阿里、京东等诸多知名企业独特编制的，旨在用系统化、流程化办法梳理软件应用服务研发经营全生命周期平安及发展趋势，帮忙从业者晋升对软件应用服务研发经营平安的了解。 平安左移，形成新型研发经营平安体系的最后一步白皮书中指出，近年来安全事件频发的次要起因，就是软件应用服务本身存在的代码安全漏洞被黑客利用攻打。依据Verizon 、Forrester 以及Gartner 等寰球出名机构、征询公司所统计公布的钻研数据来看，由程序中的代码安全漏洞以及权限设置机制等起因引发的Web应用程序威逼破绽和因代码应用层存在安全漏洞，是内部攻打和数据泄露等安全事件产生的次要起因。 在软件应用服务曾经浸透至各行业畛域中的当下，传统研发经营平安模式属于被动防御性伎俩，以防病毒、防火墙等为代表的平安性能关注的都是交付运行之后的平安问题，绝对滞后的平安伎俩无奈笼罩研发阶段代码层面的平安，其平安测试范畴绝对无限，且安全漏洞修复老本也更大。 白皮书认为，如果要解决代码所导致的平安问题，就须要思考将平安左移，从而搭建笼罩软件应用服务全生命周期的、新型研发经营平安体系。 此外，白皮书还对新型研发经营平安体系的四大特点和七大环节进行了具体介绍，其中四大特点包含： 覆盖范围更广，延长至下线停用阶段，笼罩软件应用服务全生命周期；更具普适性，抽取要害因素，不依靠于任何开发模式与体系；不止强调平安工具，同样重视平安治理，强化人员平安能力；进行经营平安数据反馈，造成平安闭环，一直优化流程实际。而七大环节则分为软件应用服务研发的要求阶段、平安需要分析阶段到上线后的公布阶段、经营阶段、停用下线阶段等七个阶段。 传统研发经营平安模式仅能对公布、经营和停用下线阶段进行爱护。而在平安左移之后，新型研发经营平安体系就可能在软件应用服务设计晚期便引入平安概念，从而让平安笼罩软件应用服务全生命周期，最终实现达成升高平安问题解决老本、全方面晋升服务利用平安和晋升人员平安能力的目标。 不难看出，平安左移是搭建新型研发经营平安体系的重要前提。 研发经营平安体系，需向麻利化、自动化演进始终以来，研发经营平安相干体系的倒退与开发模式的变动是密不可分的。随着近年来云计算的遍及，越来越多的企业开始将业务,尤其是外围业务向云原生的环境迁徙，对软件开发的品质和效率的要求一直进步。 而DevOps作为一款云原生、API所驱动的麻利开发工具，被云上企业广泛应用于软件应用服务开发和部署的过程中。白皮书认为，为适应软件应用服务开发模式逐渐向麻利化发展的趋势，研发经营平安体系也应随之向麻利化演进，可能将平安工具无缝集成到开发过程中的“DevSecOps”开发框架，将成为将来研发经营平安的要害组成部分。 平安专家建议，在构建“DevSecOps”框架中的性能时，须要重点思考危险和威逼建模、自定义代码扫描、开源软件扫描和追踪、系统配置破绽扫描、平安测试的自动化部署等平安性能。同时，用户应用 DevOps 的目标决定了其对“自动化”和“持续性”的要求尤为突出，因而在将平安工具集成到开发过程之中时，也应该遵循“自动化”和“通明”的准则。 全生命周期平安体系，已在局部畛域中胜利落地只管白皮书给出了新型研发经营平安体系的形成和实现门路，但平安左移、自动化和全生命周期平安爱护在利用实际中有着更高的要求。对于这类企业而言，抉择配套上云+云上原生平安产品组合，同样不失为另一种解决方案。 腾讯平安在7月举办的“产业平安公开课·云原生专场”中，在直播课程中对外分享了腾讯平安云原生平安经营体系的构建理念，即以云原生为核心，以平安左移、数据驱动及自动化为根本撑持，从而实现云上的全生命周期平安治理。 其中，平安左移指的是云原生平安经营体系。首先应该具备事先感知平安威逼和配置危险查看能力，既以构建平安预防体系的形式晋升整体平安程度；而数据驱动则是云原生平安经营的根本要求，通过建设云上平安数据湖对各平安产品上的数据进行收集和对立治理；最初，通过云上资产自动化盘点及云上威逼自动化响应处理等自动化技术，对收集到的云上平安问题进行主动响应和处理，最终构建出对平安威逼从感知到检测再到应答处理的全生命周期平安管理体系。 目前，腾讯平安以云原生平安经营体系为外围所打造的平安产品——腾讯平安经营核心累计为政府、金融、运营商、医疗、互联网等多个畛域提供平安保障。将来，腾讯平安将持续摸索全生命周期平安在其余产品和畛域中的利用场景和实现门路，为加强行业对于研发经营平安意识、实现平安可信生态建设提供助力。

传统研发经营模式中，平安地位绝对滞后，无奈笼罩研发阶段的平安问题。日前，《研发经营平安白皮书（2020年）》（以下简称“白皮书”）在中国信息通信研究院、中国通信标准化协会联结主办的可信云线上峰会上正式公布。该白皮书是由中国信息通信研究院牵头，联结腾讯、华为、阿里、京东等诸多知名企业独特编制的，旨在用系统化、流程化办法梳理软件应用服务研发经营全生命周期平安及发展趋势，帮忙从业者晋升对软件应用服务研发经营平安的了解。 平安左移，形成新型研发经营平安体系的最后一步白皮书中指出，近年来安全事件频发的次要起因，就是软件应用服务本身存在的代码安全漏洞被黑客利用攻打。依据Verizon 、Forrester 以及Gartner 等寰球出名机构、征询公司所统计公布的钻研数据来看，由程序中的代码安全漏洞以及权限设置机制等起因引发的Web应用程序威逼破绽和因代码应用层存在安全漏洞，是内部攻打和数据泄露等安全事件产生的次要起因。 在软件应用服务曾经浸透至各行业畛域中的当下，传统研发经营平安模式属于被动防御性伎俩，以防病毒、防火墙等为代表的平安性能关注的都是交付运行之后的平安问题，绝对滞后的平安伎俩无奈笼罩研发阶段代码层面的平安，其平安测试范畴绝对无限，且安全漏洞修复老本也更大。 白皮书认为，如果要解决代码所导致的平安问题，就须要思考将平安左移，从而搭建笼罩软件应用服务全生命周期的、新型研发经营平安体系。 此外，白皮书还对新型研发经营平安体系的四大特点和七大环节进行了具体介绍，其中四大特点包含： 覆盖范围更广，延长至下线停用阶段，笼罩软件应用服务全生命周期；更具普适性，抽取要害因素，不依靠于任何开发模式与体系；不止强调平安工具，同样重视平安治理，强化人员平安能力；进行经营平安数据反馈，造成平安闭环，一直优化流程实际。而七大环节则分为软件应用服务研发的要求阶段、平安需要分析阶段到上线后的公布阶段、经营阶段、停用下线阶段等七个阶段。 传统研发经营平安模式仅能对公布、经营和停用下线阶段进行爱护。而在平安左移之后，新型研发经营平安体系就可能在软件应用服务设计晚期便引入平安概念，从而让平安笼罩软件应用服务全生命周期，最终实现达成升高平安问题解决老本、全方面晋升服务利用平安和晋升人员平安能力的目标。 不难看出，平安左移是搭建新型研发经营平安体系的重要前提。 研发经营平安体系，需向麻利化、自动化演进始终以来，研发经营平安相干体系的倒退与开发模式的变动是密不可分的。随着近年来云计算的遍及，越来越多的企业开始将业务,尤其是外围业务向云原生的环境迁徙，对软件开发的品质和效率的要求一直进步。 而DevOps作为一款云原生、API所驱动的麻利开发工具，被云上企业广泛应用于软件应用服务开发和部署的过程中。白皮书认为，为适应软件应用服务开发模式逐渐向麻利化发展的趋势，研发经营平安体系也应随之向麻利化演进，可能将平安工具无缝集成到开发过程中的“DevSecOps”开发框架，将成为将来研发经营平安的要害组成部分。 平安专家建议，在构建“DevSecOps”框架中的性能时，须要重点思考危险和威逼建模、自定义代码扫描、开源软件扫描和追踪、系统配置破绽扫描、平安测试的自动化部署等平安性能。同时，用户应用 DevOps 的目标决定了其对“自动化”和“持续性”的要求尤为突出，因而在将平安工具集成到开发过程之中时，也应该遵循“自动化”和“通明”的准则。 全生命周期平安体系，已在局部畛域中胜利落地只管白皮书给出了新型研发经营平安体系的形成和实现门路，但平安左移、自动化和全生命周期平安爱护在利用实际中有着更高的要求。对于这类企业而言，抉择配套上云+云上原生平安产品组合，同样不失为另一种解决方案。 腾讯平安在7月举办的“产业平安公开课·云原生专场”中，在直播课程中对外分享了腾讯平安云原生平安经营体系的构建理念，即以云原生为核心，以平安左移、数据驱动及自动化为根本撑持，从而实现云上的全生命周期平安治理。 其中，平安左移指的是云原生平安经营体系。首先应该具备事先感知平安威逼和配置危险查看能力，既以构建平安预防体系的形式晋升整体平安程度；而数据驱动则是云原生平安经营的根本要求，通过建设云上平安数据湖对各平安产品上的数据进行收集和对立治理；最初，通过云上资产自动化盘点及云上威逼自动化响应处理等自动化技术，对收集到的云上平安问题进行主动响应和处理，最终构建出对平安威逼从感知到检测再到应答处理的全生命周期平安管理体系。 目前，腾讯平安以云原生平安经营体系为外围所打造的平安产品——腾讯平安经营核心累计为政府、金融、运营商、医疗、互联网等多个畛域提供平安保障。将来，腾讯平安将持续摸索全生命周期平安在其余产品和畛域中的利用场景和实现门路，为加强行业对于研发经营平安意识、实现平安可信生态建设提供助力。

一、背景AppsFlyer创建于2011年，是寰球挪动归因与营销剖析畛域的领导者，是挪动监测行业的规范。AppsFlyer建设的挪动归因与营销剖析平台，通过一系列全面的掂量和剖析解决方案，使营销人员可能倒退本人的业务并进行翻新。 AppsFlyer通过设计围绕隐衷进行构建，采纳以客户为核心的办法，每天可帮忙12,000多个品牌和6,000多个技术合作伙伴做出更好的业务决策。AppsFlyer的总部位于旧金山，目前在寰球设有18个办事处，其平台已与2,000多个广告网络集成在一起，其中包含Yahoo、Google和Bing。 在 JFrog SwampUp 2020用户大会上，AppsFlyer的DevOps平台工程师Roman Roberman介绍了他们如何基于JFrog Artifactory建设惟一可信源，从而改良了企业的制品治理品质，实现了对其研发环境的管制与自动化治理。 二、AppsFlyer晚期的制品治理在采纳JFrog Artifactory之前，依照Roberman的说法，AppsFlyer的制品治理就是“真正的烂摊子”。整个公司的制品由多种外部和内部的制品仓库独特治理，有些类型的制品还没有用制品仓库进行治理，如： · 外部的Docker镜像核心 · 内部的公共npm仓库 · 用s3作为本地的Maven仓库 · 通常用s3作为定制的通用类型仓库 · 不足实用于Python的pip仓库 整个制品管理体系简单而凌乱，不得不为每个我的项目都配置多个制品仓库，其中甚至会包含一些内部的公共仓库，如下图所示： 这种架构与模式带来了很多问题。如，有时内部的仓库资源可能拜访不到，或者当去内部仓库拉取依赖时却发现相应的制品曾经被删掉了；为治理所有的资源不得不应用泛滥独立的认证体系，凭证很难跟踪；很难对制品的存储地位和起源进行跟踪和溯源等等。 随着业务规模的倒退，AppsFlyer须要更加规模化的、集中统一的治理形式。比方： 1）须要晋升制品部署、公布的速度和可靠性； 2）一站式治理，而不是不同类型的制品存储到不同的仓库； 3）制品管理系统应用对立的认证体系； 4）所有制品都纳入治理。 应用JFrog Artifactory之后，AppsFlyer实现了上述所有的指标。 三、基于Artifactory的惟一可信源AppsFlyer抉择了Artifactory作为制品治理的惟一可信源，晋升了其软件部署的速度和效率，并进步了其软件版本的稳定性和可靠性。 目前，AppsFlyer制品管理体系蕴含两个Artifactory集群，一个在欧洲，这个是主生产集群，提供所有销售业务；另一个在美国，次要进行备份。两个集群通过同一个JFrog Mission Control进行对立治理。如下图所示： 所有的机器由Terraform部署，而Artifactory通过团队定制开发的Chef cookbook主动装置。数据都存储在S3，每个节点还都设置了缓存以放慢访问速度。Mission Control提供了良好的视角能够同时监督两个集群，并且当欧洲集群新建了一个仓库时，能够在美国节点主动创立一个对应的备份仓库。 在基于Artifactory建设了惟一可信源之后，之前的问题都失去了解决，当初能够对所有制品进行集中统一的治理了，而且能够改良和减速研发流程。 如下图所示： 在全面实施基于Artifactory的治理计划之前，AppsFlyer对利用成果进行了POC验证，通过在每种计划下不同的拉取制品场景来进行数据比拟。首先，咱们应用了50个节点作为基准，别离从Artifactory和原来的仓库并行拉取制品，其后果如下。很显著，应用Artifactory的效率更高。 而后，再把节点数减少到300，ARITfactory的效率也很显著，如下所示： AppsFlyer也测试了将制品上传集群的一个节点，而后从另一个节点拉取；或者将制品上传到欧洲的集群，而后从美国集群拉取；或者删除集群中的某个节点再进行复原，而后确认是否在确定的工夫内复原胜利；等等。所有的测试都失去了称心的后果。 四、基于Artifactory的附加价值除了建设惟一可信源，晋升公布速度和效率外，基于Artifactory进行制品治理还为AppsFlyer带来了很多附加的价值： 1）齐备的内嵌文档。如下图所示，不须要再破费大量工夫去学习如何操作特定类型的仓库，用户间接参考“Set Me Up”即可； 2）备份和清理。之前，没有也无奈所备份。当初通过备份，能够在生产环境中清理大量不必的制品，从而节俭大量的资源和老本； 3）对立接口。这十分重要，当初能够用过同一个URL，同一个接口，一站式治理组织内的所有制品； 4）对立认证。当初能够对接企业的LDAP，应用统一的认证体系实现对立治理。 五、总结AppsFlyer通过基于JFrog Artifactory建设惟一可信源，将企业外部制品治理的无序凌乱，改良为集中、对立、自动化的治理，晋升了利用部署和交付的速度、效率和品质，而且也为制品治理提供了很多附加的价值。 **欢送观看JFrog杰蛙每周二在线课堂，点击报名： https://www.bagevent.com/even...**

一、背景AppsFlyer创建于2011年，是寰球挪动归因与营销剖析畛域的领导者，是挪动监测行业的规范。AppsFlyer建设的挪动归因与营销剖析平台，通过一系列全面的掂量和剖析解决方案，使营销人员可能倒退本人的业务并进行翻新。 AppsFlyer通过设计围绕隐衷进行构建，采纳以客户为核心的办法，每天可帮忙12,000多个品牌和6,000多个技术合作伙伴做出更好的业务决策。AppsFlyer的总部位于旧金山，目前在寰球设有18个办事处，其平台已与2,000多个广告网络集成在一起，其中包含Yahoo、Google和Bing。 在 JFrog SwampUp 2020用户大会上，AppsFlyer的DevOps平台工程师Roman Roberman介绍了他们如何基于JFrog Artifactory建设惟一可信源，从而改良了企业的制品治理品质，实现了对其研发环境的管制与自动化治理。 二、AppsFlyer晚期的制品治理在采纳JFrog Artifactory之前，依照Roberman的说法，AppsFlyer的制品治理就是“真正的烂摊子”。整个公司的制品由多种外部和内部的制品仓库独特治理，有些类型的制品还没有用制品仓库进行治理，如： · 外部的Docker镜像核心 · 内部的公共npm仓库 · 用s3作为本地的Maven仓库 · 通常用s3作为定制的通用类型仓库 · 不足实用于Python的pip仓库 整个制品管理体系简单而凌乱，不得不为每个我的项目都配置多个制品仓库，其中甚至会包含一些内部的公共仓库，如下图所示： 这种架构与模式带来了很多问题。如，有时内部的仓库资源可能拜访不到，或者当去内部仓库拉取依赖时却发现相应的制品曾经被删掉了；为治理所有的资源不得不应用泛滥独立的认证体系，凭证很难跟踪；很难对制品的存储地位和起源进行跟踪和溯源等等。 随着业务规模的倒退，AppsFlyer须要更加规模化的、集中统一的治理形式。比方： 1）须要晋升制品部署、公布的速度和可靠性； 2）一站式治理，而不是不同类型的制品存储到不同的仓库； 3）制品管理系统应用对立的认证体系； 4）所有制品都纳入治理。 应用JFrog Artifactory之后，AppsFlyer实现了上述所有的指标。 三、基于Artifactory的惟一可信源AppsFlyer抉择了Artifactory作为制品治理的惟一可信源，晋升了其软件部署的速度和效率，并进步了其软件版本的稳定性和可靠性。 目前，AppsFlyer制品管理体系蕴含两个Artifactory集群，一个在欧洲，这个是主生产集群，提供所有销售业务；另一个在美国，次要进行备份。两个集群通过同一个JFrog Mission Control进行对立治理。如下图所示： 所有的机器由Terraform部署，而Artifactory通过团队定制开发的Chef cookbook主动装置。数据都存储在S3，每个节点还都设置了缓存以放慢访问速度。Mission Control提供了良好的视角能够同时监督两个集群，并且当欧洲集群新建了一个仓库时，能够在美国节点主动创立一个对应的备份仓库。 在基于Artifactory建设了惟一可信源之后，之前的问题都失去了解决，当初能够对所有制品进行集中统一的治理了，而且能够改良和减速研发流程。 如下图所示： 在全面实施基于Artifactory的治理计划之前，AppsFlyer对利用成果进行了POC验证，通过在每种计划下不同的拉取制品场景来进行数据比拟。首先，咱们应用了50个节点作为基准，别离从Artifactory和原来的仓库并行拉取制品，其后果如下。很显著，应用Artifactory的效率更高。 而后，再把节点数减少到300，ARITfactory的效率也很显著，如下所示： AppsFlyer也测试了将制品上传集群的一个节点，而后从另一个节点拉取；或者将制品上传到欧洲的集群，而后从美国集群拉取；或者删除集群中的某个节点再进行复原，而后确认是否在确定的工夫内复原胜利；等等。所有的测试都失去了称心的后果。 四、基于Artifactory的附加价值除了建设惟一可信源，晋升公布速度和效率外，基于Artifactory进行制品治理还为AppsFlyer带来了很多附加的价值： 1）齐备的内嵌文档。如下图所示，不须要再破费大量工夫去学习如何操作特定类型的仓库，用户间接参考“Set Me Up”即可； 2）备份和清理。之前，没有也无奈所备份。当初通过备份，能够在生产环境中清理大量不必的制品，从而节俭大量的资源和老本； 3）对立接口。这十分重要，当初能够用过同一个URL，同一个接口，一站式治理组织内的所有制品； 4）对立认证。当初能够对接企业的LDAP，应用统一的认证体系实现对立治理。 五、总结AppsFlyer通过基于JFrog Artifactory建设惟一可信源，将企业外部制品治理的无序凌乱，改良为集中、对立、自动化的治理，晋升了利用部署和交付的速度、效率和品质，而且也为制品治理提供了很多附加的价值。 **欢送观看JFrog杰蛙每周二在线课堂，点击报名： https://www.bagevent.com/even...**

近日，驰名数码摄像机厂商佳能被曝疑似蒙受Maze团伙勒索攻打，其中影响蕴含电子邮件、微软团队、美国网站以及其余外部应用程序。 据外媒报道称，佳能image.canon云照片和视频存储服务的可疑中断，导致其收费10GB存储性能的用户数据失落。由BleepingComputer音讯称，佳能正在经验“影响多个应用程序、团队、电子邮件和其余零碎的广泛传播的零碎问题，目前可能不可用”。 这样的勒索攻打事件是否似曾相识？这几乎神还原佳明 Garmin不久前蒙受的歹意勒索病毒攻打事件。面对频发的勒索黑产攻打事件，企业如何转后手为先手，让平安变得更被动、更前置？而随着数字化时代全面到来，企业又该如何从零开始建设数据安全防护能力？ 进击的Maze，从“业务翻新”到“商业化运作”作为一款间接将受害者数据公布到网站并进行勒索的元祖，Maze团伙也叫ChaCha勒索病毒，国内安全厂商称其为“迷宫”。 在2019年5月被发现之初，Maze团伙应用翻新的加密技能就给平安厂商留下了粗浅的印象。过后的Maze团伙受同行启发，加密模式采纳RSA+Salsa20联合形式加密, 并且加密针对每个文件随机生成不同的后缀名，这给平安专家破解带来了极大的难度。 同时，该团伙善于应用FalloutEK破绽利用工具通过网页挂马等形式流传。而被挂马的网页，多见于黄赌毒相干页面，通常会逐渐扩充到盗版软件、游戏外挂、盗版影视作品下载，以及某些软件内嵌的广告页面。 只管Maze团伙不是最早从事网络勒索勾当的，但相对是最快实现商业化运作的团伙。该团伙在网上开办了一个专用网站，用于颁布一些受害者的信息威胁赎金。去年12月，Maze团伙就向北美最当先的电缆制造商之一Southwire勒索了600万元美金。如果Southwire不交赎金，Maze勒索病毒团伙会在网站上颁布该公司的数据，试图利用这种办法，逼迫Southwire交赎金。 尔后，雄心勃勃的Maze团伙频频被爆新动作，一直刷新人们的认知。往年6月，该团伙宣称其曾经窃取了波及LG与美国大公司的我的项目专有信息，包含LG为美国大型公司开发的40GB Python代码。值得注意的是，该勒索软件还会校验计算机语言，如果匹配上就不会进行文件加密。 一直变革的加密技能、规范化的商业运作、再创天价的解密赎金……使之名声大噪的Maze团伙胜利吸引了Ragnar Locker和LockBit两个规模不小的勒索团伙入伙，单方合作公布受害者数据，独特迈向了“互惠互利、谐和倒退”的路线。 勒索病毒乘势来袭，进攻入侵才是解决之道对于大型企业而言，数据泄露带来的不止有经济上的损失，还会重大影响企业形象，使本身失去公众信赖。因而，面对这种以泄露数据为伎俩的勒索攻打，就算企业有数据备份，也只能被迫抉择领取赎金。 据《腾讯平安2020上半年勒索病毒报告》显示，整个上半年寰球企业蒙受勒索病毒打击的事件仍然高频产生。而老牌勒索家族的攻打对象已由过来的广撒网、无差别模式转变为具备勒索后劲的企业，这一转变也让勒索攻打的收益转化更为高效。 基于过来从企业中播种的丰富利益，勒索病毒攻打将指标更多投向企业用户。从勒索病毒影响的行业看，传统企业、教育、医疗、政府机构蒙受攻打最为重大，占比顺次为42%、18%、15%、15%。同时互联网、金融、能源也受到勒索病毒攻打不同水平的影响。 对于个人用户而言，面对勒索病毒的恐怖之处在于无奈破解，一旦中招更多时候会抉择重装系统，以致数据失落带来无法估量的损失。甚至能够说，勒索病毒如同一颗无奈被齐全切除的毒瘤，当时预防比预先解决更为要害。 腾讯平安依据多年与勒索病毒战斗的教训，总结了“三不三要”思路。 l 不上钩：题目吸引人的未知邮件不要点开 l 不关上：不轻易关上电子邮件附件 l 不点击：不随便点击电子邮件中附带网址 l 要备份：重要材料要备份 l 要确认：开启电子邮件前确认发件人可信 l 要更新：零碎补丁/安全软件病毒库放弃实时更新 腾讯平安专家预测，勒索病毒将来攻打将出现流传场景多样化、攻打指标转向企业、更新迭代放慢、勒索赎金定制化、病毒开发门槛升高、勒索病毒产业化、病毒多平台扩散等趋势。 从策略视角切入，构建全生命周期数据安全防护能力从2017年WannaCry勒索病毒寰球范畴内大暴发，到近期B站百大UP主党妹被勒索，再到近期佳明被勒索1000万美元赎金事件，来势汹汹的勒索病毒事件一直引发社会各界对于数据安全和隐衷爱护的关注。 尤其在云时代下，随着企业产业互联网的降级，企业数据开始参加到企业的生产当中，成为企业的重要生产资料甚至是外围资产。也因而，数据所面临的危险一劳永逸，数据泄露给企业造成的损失也越来越大。 “外围数据流的所有环节都是重点，而这个重点也是难点。”腾讯平安数据安全负责人彭思翔示意：因为要将数据流的所有环节进行梳理，包含人的治理、行为的管制、代码的健壮性等一系列问题囊括到数据安全的防护措施中是十分艰难的。 面对全新的平安挑战，腾讯平安综合使用数据安全治理教训和数据保护技术打造了数据安全治理核心、数据加密服务、密钥管理系统、凭据管理系统、数据安全审计、堡垒机、敏感数据处理等七大产品体系，针对性地在数据全生命周期每个阶段提供爱护，帮忙用户克服数据安全防护的“四大难”问题。 在云数据时代，平安不仅是企业生存问题，更是倒退问题。对于企业而言，数据全生命周期防护是一种深刻数据流的防护伎俩，其从数据的产生、传输、存储、解决、共享、应用、销毁等环节动手，建设了一套全生命周期的防护措施。这种贯通始终的防护模式可能防止木桶原理，避免一个短板导致企业数据安全全盘解体。

近日，驰名数码摄像机厂商佳能被曝疑似蒙受Maze团伙勒索攻打，其中影响蕴含电子邮件、微软团队、美国网站以及其余外部应用程序。 据外媒报道称，佳能image.canon云照片和视频存储服务的可疑中断，导致其收费10GB存储性能的用户数据失落。由BleepingComputer音讯称，佳能正在经验“影响多个应用程序、团队、电子邮件和其余零碎的广泛传播的零碎问题，目前可能不可用”。 这样的勒索攻打事件是否似曾相识？这几乎神还原佳明 Garmin不久前蒙受的歹意勒索病毒攻打事件。面对频发的勒索黑产攻打事件，企业如何转后手为先手，让平安变得更被动、更前置？而随着数字化时代全面到来，企业又该如何从零开始建设数据安全防护能力？ 进击的Maze，从“业务翻新”到“商业化运作”作为一款间接将受害者数据公布到网站并进行勒索的元祖，Maze团伙也叫ChaCha勒索病毒，国内安全厂商称其为“迷宫”。 在2019年5月被发现之初，Maze团伙应用翻新的加密技能就给平安厂商留下了粗浅的印象。过后的Maze团伙受同行启发，加密模式采纳RSA+Salsa20联合形式加密, 并且加密针对每个文件随机生成不同的后缀名，这给平安专家破解带来了极大的难度。 同时，该团伙善于应用FalloutEK破绽利用工具通过网页挂马等形式流传。而被挂马的网页，多见于黄赌毒相干页面，通常会逐渐扩充到盗版软件、游戏外挂、盗版影视作品下载，以及某些软件内嵌的广告页面。 只管Maze团伙不是最早从事网络勒索勾当的，但相对是最快实现商业化运作的团伙。该团伙在网上开办了一个专用网站，用于颁布一些受害者的信息威胁赎金。去年12月，Maze团伙就向北美最当先的电缆制造商之一Southwire勒索了600万元美金。如果Southwire不交赎金，Maze勒索病毒团伙会在网站上颁布该公司的数据，试图利用这种办法，逼迫Southwire交赎金。 尔后，雄心勃勃的Maze团伙频频被爆新动作，一直刷新人们的认知。往年6月，该团伙宣称其曾经窃取了波及LG与美国大公司的我的项目专有信息，包含LG为美国大型公司开发的40GB Python代码。值得注意的是，该勒索软件还会校验计算机语言，如果匹配上就不会进行文件加密。 一直变革的加密技能、规范化的商业运作、再创天价的解密赎金……使之名声大噪的Maze团伙胜利吸引了Ragnar Locker和LockBit两个规模不小的勒索团伙入伙，单方合作公布受害者数据，独特迈向了“互惠互利、谐和倒退”的路线。 勒索病毒乘势来袭，进攻入侵才是解决之道对于大型企业而言，数据泄露带来的不止有经济上的损失，还会重大影响企业形象，使本身失去公众信赖。因而，面对这种以泄露数据为伎俩的勒索攻打，就算企业有数据备份，也只能被迫抉择领取赎金。 据《腾讯平安2020上半年勒索病毒报告》显示，整个上半年寰球企业蒙受勒索病毒打击的事件仍然高频产生。而老牌勒索家族的攻打对象已由过来的广撒网、无差别模式转变为具备勒索后劲的企业，这一转变也让勒索攻打的收益转化更为高效。 基于过来从企业中播种的丰富利益，勒索病毒攻打将指标更多投向企业用户。从勒索病毒影响的行业看，传统企业、教育、医疗、政府机构蒙受攻打最为重大，占比顺次为42%、18%、15%、15%。同时互联网、金融、能源也受到勒索病毒攻打不同水平的影响。 对于个人用户而言，面对勒索病毒的恐怖之处在于无奈破解，一旦中招更多时候会抉择重装系统，以致数据失落带来无法估量的损失。甚至能够说，勒索病毒如同一颗无奈被齐全切除的毒瘤，当时预防比预先解决更为要害。 腾讯平安依据多年与勒索病毒战斗的教训，总结了“三不三要”思路。 l 不上钩：题目吸引人的未知邮件不要点开 l 不关上：不轻易关上电子邮件附件 l 不点击：不随便点击电子邮件中附带网址 l 要备份：重要材料要备份 l 要确认：开启电子邮件前确认发件人可信 l 要更新：零碎补丁/安全软件病毒库放弃实时更新 腾讯平安专家预测，勒索病毒将来攻打将出现流传场景多样化、攻打指标转向企业、更新迭代放慢、勒索赎金定制化、病毒开发门槛升高、勒索病毒产业化、病毒多平台扩散等趋势。 从策略视角切入，构建全生命周期数据安全防护能力从2017年WannaCry勒索病毒寰球范畴内大暴发，到近期B站百大UP主党妹被勒索，再到近期佳明被勒索1000万美元赎金事件，来势汹汹的勒索病毒事件一直引发社会各界对于数据安全和隐衷爱护的关注。 尤其在云时代下，随着企业产业互联网的降级，企业数据开始参加到企业的生产当中，成为企业的重要生产资料甚至是外围资产。也因而，数据所面临的危险一劳永逸，数据泄露给企业造成的损失也越来越大。 “外围数据流的所有环节都是重点，而这个重点也是难点。”腾讯平安数据安全负责人彭思翔示意：因为要将数据流的所有环节进行梳理，包含人的治理、行为的管制、代码的健壮性等一系列问题囊括到数据安全的防护措施中是十分艰难的。 面对全新的平安挑战，腾讯平安综合使用数据安全治理教训和数据保护技术打造了数据安全治理核心、数据加密服务、密钥管理系统、凭据管理系统、数据安全审计、堡垒机、敏感数据处理等七大产品体系，针对性地在数据全生命周期每个阶段提供爱护，帮忙用户克服数据安全防护的“四大难”问题。 在云数据时代，平安不仅是企业生存问题，更是倒退问题。对于企业而言，数据全生命周期防护是一种深刻数据流的防护伎俩，其从数据的产生、传输、存储、解决、共享、应用、销毁等环节动手，建设了一套全生命周期的防护措施。这种贯通始终的防护模式可能防止木桶原理，避免一个短板导致企业数据安全全盘解体。

WeCube简介微众银行在分布式架构实际的过程中，发现将银行外围零碎构建于分布式架构之上，会遇到一些与传统单体利用不同的痛点（例如，服务器增多，部署难度大；调用链长，全链路跟踪艰难； 零碎简单，问题定位工夫长等），在逐渐解决这些痛点的过程中，总结了一套IT治理的方法论和最佳实际，并研发了与之配套的IT管理工具体系。WeCube就是将该套方法论和最佳实际，从微众外部泛滥IT管理工具体系中提炼进去，整合成一套开箱即用的、开源的、一站式IT架构治理和运维管理工具，次要用于简化分布式架构IT治理，并能够通过插件进行性能扩大。 2.6.0版本次要内容新增个性WeCube Platform - 减少插件包批量注册、登记性能; WeCube Platform - CORE DB降级机制; WeCube Platform - 减少插件权限治理; WeCube Platform - 集成离线帮忙文档; CMDB Plugin - 减少查问执行数据比照; Artifact Plugin – 反对第三方物料仓库(Nexus); Monitor Plugin - 减少存活自检性能; Monitor Plugin - 反对数据长久化到内部mysql; ServiceManagement Plugin - 减少工作超时反对; ServiceManagement Plugin - 减少数据排序反对; Saltstack Plugin - 多脚本执行反对。 性能改良WeCube Platform - 增加平台版本信息; WeCube Platform - 插件最佳实际导出导入支持系统参数; WeCube Platform - 修复插件版本与运行实例匹配没有关联状态问题; WeCube Platform - 修复最佳实际不能批改字段的映射类型和是否敏感属性; WeCube Platform - 批量执行不反对取得非本身动静属性; WeCube Platform - 编排权限反对在下拉框外设置; WeCube Platform - 反对画布定位核心; WeCube Platform - 优化获取插件packages效率; WeCube Platform - 优化页面获取menus效率; WeCube Platform - 优化页面获取models效率; CMDB Plugin - 反对表达式解析获取架构图连线数据; CMDB Plugin - 工夫/明码类型表单项反对; CMDB Plugin - 减少架构变更减少二次确认; CMDB Plugin - 优化抉择框清空及搜寻性能; CMDB Plugin - 修复根底数据管理及日志列表无奈失常显示; Artifact Plugin – 修复打印日志时差问题; Artifact Plugin – 配置值复用抉择、减少是否解压字段; Artifact Plugin – 修复物料治理大小写敏感问题; Artifact Plugin – 修复报错信息没有展现问题; Artifact Plugin – 修复空文件门路展现多余'|'符号问题; Monitor Plugin - 优化对象反对视图通用化; Saltstack Plugin - 修复命令执行脚本带参数(空格距离)问题; Saltstack Plugin - 修复用户组治理字段数据为用户:组格局出错问题。 ...

原文：https://news.mydrivers.com/1/...Linus Torvalds明天签订公布了最新的Linux 5.8版零碎内核，此时间隔新版发表只有一个半月工夫，不仅停顿超快，而且这次变动十分之大，用大神的话说就是“really big”。 大神示意，5.8版本的变动可与当初的4.9版本相媲美，最后预报的时候就走漏会有超过1.4万个文件要批改，大概1.4万个未合并的commit，还有8万行左右的新代码。 最终，新版零碎内核源大概20％的文件都做了批改，这个比例相当惊人。 这么大规模的改变，带来的新个性、新变动也是相当丰盛：高通Adreno 405/640/650 GPU反对，新的Spectre幽灵安全补丁，exFAT文件格式加强，Radeon显卡驱动，IBM Power10处理器反对，等等。

6 月 18 日 24 时，2020 年的 618 大促落下帷幕，京东 618 大促期间累计下单金额达到 2692 亿元，创下新纪录。 与今年不同，往年 618 是京东外围业务全面上云的第一年，也是京东交融人工智能、云计算、物联网等业务板块降级为京东智联云之后其技术能力的第一次大考。 面对翻新高的云端数据和流量洪峰，京东技术扛住了，这次要得益于作为京东技术基石的京东智联云全栈出征，为 618 搭建了一套巩固且高弹性的技术底座，撑持超大流量、超高并发的技术平台。 近日，京东智联云技术沙龙在线上举办，来自京东的 5 位演讲嘉宾带来了各自的主题分享，别离从分布式图搜零碎、分布式文件系统、全方位平安体系、数据库等角度，揭秘京东技术全栈是如何为往年的 618 大促提供技术撑持的。 朱洪银，京东软件工程师 演讲题目：《撑持618大促流量洪峰利器——分布式文件系统ChubaoFS》 演讲精髓： 往年的 618 大促，京东面临着很多难题与挑战，这次要包含计算和存储拆散的需要，数据的生产者和消费者应用不必的协定拜访文件，容器平台须要提供可长久化的分布式存储平台，提供更大的磁盘空间，以及对海量小文件敌对、同时能够提供高性能、高可用、高可扩展性。 这些挑战，被京东自研的交融分布式文件系统与对象存储服务的 ChubaoFS一一化解。 从架构上来看，ChubaoFS 蕴含 Master、MetaNode、DataNode、Client 四个模块，具备高性能、多租户、通用存储引擎、高可扩展性、兼容POSIX接口、反对对象存储 6 个要害特色。 ChubaoFS 的元数据子系统是由多个 MetaNode 节点组成的，能够程度扩容，在一个 MetaNode 上能够散布多个 MetaPartition。 在京东，ChubaoFS 曾经稳固服务于 2000 多个利用以及在线业务，为公司节俭了上千台机器，老本节约成果显著。 朱洪银介绍到，618 大促期间，客户端的数据剧增，各个业务方可能依据访问量的变动进行大量扩容，这时 Master 就会遇到带宽瓶颈，如果几十万个 Cilent 同时拜访一台机器，会对一台机器造成很大的压力，所以 ChubaoFS 在两头加了一层以缓存零碎的元数据，这样客户端几十万的申请，最终打到 Master 集群上可能会放大 1000 倍，Master 的压力明显降低。 第二点是大促期间的热点数据拜访。面对热点数据拜访场景，有三种解决伎俩，第一种是 S3；如果应用的是 POSIX，则间接开启 cache 缓存选项，晋升读写性能；第三种是从集群的角度，在创立 vol 时会多调配一些 DataPartition 和 MetaPartition 资源，减小每台机器的 IO 压力和内存压力，从而晋升响应速度。 ...

6 月 18 日 24 时，2020 年的 618 大促落下帷幕，京东 618 大促期间累计下单金额达到 2692 亿元，创下新纪录。 与今年不同，往年 618 是京东外围业务全面上云的第一年，也是京东交融人工智能、云计算、物联网等业务板块降级为京东智联云之后其技术能力的第一次大考。 面对翻新高的云端数据和流量洪峰，京东技术扛住了，这次要得益于作为京东技术基石的京东智联云全栈出征，为 618 搭建了一套巩固且高弹性的技术底座，撑持超大流量、超高并发的技术平台。 近日，京东智联云技术沙龙在线上举办，来自京东的 5 位演讲嘉宾带来了各自的主题分享，别离从分布式图搜零碎、分布式文件系统、全方位平安体系、数据库等角度，揭秘京东技术全栈是如何为往年的 618 大促提供技术撑持的。 朱洪银，京东软件工程师 演讲题目：《撑持618大促流量洪峰利器——分布式文件系统ChubaoFS》 演讲精髓： 往年的 618 大促，京东面临着很多难题与挑战，这次要包含计算和存储拆散的需要，数据的生产者和消费者应用不必的协定拜访文件，容器平台须要提供可长久化的分布式存储平台，提供更大的磁盘空间，以及对海量小文件敌对、同时能够提供高性能、高可用、高可扩展性。 这些挑战，被京东自研的交融分布式文件系统与对象存储服务的 ChubaoFS一一化解。 从架构上来看，ChubaoFS 蕴含 Master、MetaNode、DataNode、Client 四个模块，具备高性能、多租户、通用存储引擎、高可扩展性、兼容POSIX接口、反对对象存储 6 个要害特色。 ChubaoFS 的元数据子系统是由多个 MetaNode 节点组成的，能够程度扩容，在一个 MetaNode 上能够散布多个 MetaPartition。 在京东，ChubaoFS 曾经稳固服务于 2000 多个利用以及在线业务，为公司节俭了上千台机器，老本节约成果显著。 朱洪银介绍到，618 大促期间，客户端的数据剧增，各个业务方可能依据访问量的变动进行大量扩容，这时 Master 就会遇到带宽瓶颈，如果几十万个 Cilent 同时拜访一台机器，会对一台机器造成很大的压力，所以 ChubaoFS 在两头加了一层以缓存零碎的元数据，这样客户端几十万的申请，最终打到 Master 集群上可能会放大 1000 倍，Master 的压力明显降低。 第二点是大促期间的热点数据拜访。面对热点数据拜访场景，有三种解决伎俩，第一种是 S3；如果应用的是 POSIX，则间接开启 cache 缓存选项，晋升读写性能；第三种是从集群的角度，在创立 vol 时会多调配一些 DataPartition 和 MetaPartition 资源，减小每台机器的 IO 压力和内存压力，从而晋升响应速度。 ...

Docker技术入门与实战第2版-高清文字版 下载地址 https://pan.baidu.com/s/1bAoRQQlvBa-PXy5lgIlxUg 扫码上面二维码关注公众号回复100011 获取分享码 本书目录构造如下: 第一局部　根底入门 第1章　初识容器与Docker 1.1　什么是Docker 1.2　为什么要应用Docker 1.3　Docker与虚拟化 1.4　本章小结 第2章　外围概念与装置配置 2.1　外围概念 2.2　装置Docker 2.3　配置Docker服务 2.4　举荐实际环境 2.5　本章小结 第3章　应用Docker镜像 3.1　获取镜像 3.2　查看镜像信息 3.3　搜查镜像 3.4　删除镜像 3.5　创立镜像 3.6　存出和载入镜像 3.7　上传镜像 3.8　本章小结 第4章　操作Docker容器 4.1　创立容器 4.2　终止容器 4.3　进入容器 4.4　删除容器 4.5　导入和导出容器 4.6　本章小结 第5章　拜访Docker仓库 5.1　Docker　Hub公共镜像市场 ...

Docker技术入门与实战 下载地址 https://pan.baidu.com/s/1bAoRQQlvBa-PXy5lgIlxUg 扫码上面二维码关注公众号回复100011 获取分享码 本书目录构造如下: 第一局部　根底入门 第1章　初识容器与Docker 1.1　什么是Docker 1.2　为什么要应用Docker 1.3　Docker与虚拟化 1.4　本章小结 第2章　外围概念与装置配置 2.1　外围概念 2.2　装置Docker 2.3　配置Docker服务 2.4　举荐实际环境 2.5　本章小结 第3章　应用Docker镜像 3.1　获取镜像 3.2　查看镜像信息 3.3　搜查镜像 3.4　删除镜像 3.5　创立镜像 3.6　存出和载入镜像 3.7　上传镜像 3.8　本章小结 第4章　操作Docker容器 4.1　创立容器 4.2　终止容器 4.3　进入容器 4.4　删除容器 4.5　导入和导出容器 4.6　本章小结 第5章　拜访Docker仓库 5.1　Docker　Hub公共镜像市场 ...

背景某我的项目数据库磁盘告警，磁盘使用率靠近100% $ df -ThFilesystem Type Size Used Avail Use% Mounted on/dev/vda1 ext4 99G 60G 35G 64% /devtmpfs devtmpfs 32G 0 32G 0% /devtmpfs tmpfs 32G 69M 32G 1% /dev/shmtmpfs tmpfs 32G 7.8M 32G 1% /runtmpfs tmpfs 32G 0 32G 0% /sys/fs/cgroup/dev/vdc1 ext4 99G 94G 52M 100% /u01/oracle/dev/vdb4 ext3 99G 30G 64G 32% /soatmpfs tmpfs 6.3G 0 6.3G 0% /run/user/1002tmpfs tmpfs 6.3G 52K 6.3G 1% /run/user/1003tmpfs tmpfs 6.3G 0 6.3G 0% /run/user/1005能够看到/dev/vdc1使用率曾经100% ...

CentOS7系统管理与运维实战 下载地址 https://pan.baidu.com/s/1KFHVI-XjGaLMrh39WuhyCw 扫码上面二维码关注公众号回复100007 获取分享码 本书目录构造如下: 第 1章开启 Linux系统管理与运维的大门.....................................1 1.1 你必须晓得的 Linux版本问题...............................................1 1.1.1 Linux的内核版本.............................................................1 1.1.2 Linux的发行版本.............................................................2 1.2 CentOS之于Linux............................................................2 1.2.1 CentOS简介 ..................................................................2 1.2.2 CentOS 7的最新改良.......................................................3 1.3 Linux运维工程师的技能 ........................................................3 1.3.1 零碎和零碎服务................................................................4 1.3.2 网络常识.........................................................................4 1.4 小结..................................................................................5 第 2章跟我学 CentOS的装置......................................................6 2.1 装置 CentOS必须晓得的基础知识...........................................6 2.1.1 磁盘分区.........................................................................6 2.1.2 动态分区的毛病及逻辑卷治理简介 ........................................7 2.1.3 虚拟化和 VMwareWorkstation简介...................................8 2.1.4 下载最新的 CentOS装置版本............................................. 9 2.2 装置 CentOS.....................................................................10 2.2.1 创立虚拟机......................................................................10 2.2.2 光盘装置 CentOS 7..........................................................12 2.2.3 U盘装置 CentOS 7...........................................................20 2.2.4 Windows 7 CentOS 7双系统装置 .....................................21 2.2.5 网络装置.........................................................................24 2.3 Linux的登录........................................................................24 2.3.1 首次配置与本地登录...........................................................25 2.3.2 近程登录..........................................................................27 2.4 从 CentOS 6.5降级到 CentOS7...........................................28 2.4.1 降级危险...........................................................................29 ...

作者：Myths链接：https://blog.mythsman.com/201...前言因为工作须要，最近从新开始收拾shell脚本。尽管绝大部分命令本人平时也常常应用，然而在写成脚本的时候总感觉写的很难看。而且当我在看其他人写的脚本的时候，总感觉难以浏览。毕竟shell脚本这个货色不算是正经的编程语言，他更像是一个工具，用来杂糅不同的程序供咱们调用。 因而很多人在写的时候也是想到哪里写到哪里，基本上都像是一段超长的main函数，不忍直视。同时，因为历史起因，shell有很多不同的版本，而且也有很多有雷同性能的命令须要咱们进行取舍，以至于代码的标准很难对立。 思考到下面的这些起因，我查阅了一些相干的文档，发现这些问题其实很多人都思考过，而且  也造成了一些不错的文章，然而还是有点零散。因而我就在这里把这些文章略微整顿了一下，作为当前我本人写脚本的技术规范。 代码格调标准结尾有“蛇棒” 所谓shebang其实就是在很多脚本的第一行呈现的以#!结尾的正文，他指明了当咱们没有指定解释器的时候默认的解释器，个别可能是上面这样： #!/bin/bash当然，解释器有很多种，除了bash之外，咱们能够用上面的命令查看本机反对的解释器: $ cat /etc/shells#/etc/shells: valid login shells/bin/sh/bin/dash/bin/bash/bin/rbash/usr/bin/screen当咱们间接应用./a.sh来执行这个脚本的时候，如果没有shebang，那么它就会默认用$SHELL指定的解释器，否则就会用shebang指定的解释器。 这种形式是咱们举荐的应用形式。 代码有正文正文，显然是一个常识，不过这里还是要再强调一下，这个在shell脚本里尤为重要。因为很多单行的shell命令不是那么浅显易懂，没有正文的话在保护起来会让人尤其的头大。 正文的意义不仅在于解释用处，而在于通知咱们注意事项，就像是一个README。 具体的来说，对于shell脚本，正文个别包含上面几个局部： shebang脚本的参数脚本的用处脚本的注意事项脚本的写作工夫，作者，版权等各个函数前的阐明正文一些较简单的单行命令正文参数要标准这一点很重要，当咱们的脚本须要承受参数的时候，咱们肯定要先判断参数是否合乎标准，并给出适合的回显，不便使用者理解参数的应用。 起码，起码，咱们至多得判断下参数的个数吧： if [[ $# != 2 ]];then     echo "Parameter incorrect."     exit 1fi变量和魔数个别状况下咱们会将一些重要的环境变量定义在结尾，确保这些变量的存在。 source /etc/profileexport PATH=”/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/apps/bin/”这种定义形式有一个很常见的用处，最典型的利用就是，当咱们本地装置了很多java版本时，咱们可能须要指定一个java来用。那么这时咱们就会在脚本结尾从新定义JAVA_HOME以及PATH变量来进行管制。同时，一段好的代码通常是不会有很多硬编码在代码里的“魔数”的。如果肯定要有，通常是用一个变量的模式定义在结尾，而后调用的时候间接调用这个变量，这样不便日后的批改。 缩进有规矩对于shell脚本，缩进是个大问题。因为很多须要缩进的中央(比方if,for语句)都不长，所有很多人都懒得去缩进，而且很多人不习惯用函数，导致缩进性能被弱化。 其实正确的缩进是很重要的，尤其是在写函数的时候，否则咱们在浏览的时候很容易把函数体跟间接执行的命令搞混。 常见的缩进办法次要有”soft tab”和”hard tab”两种。 所谓soft tab就是应用n个空格进行缩进(n通常是2或4)所谓hard tab当然就是指实在的\t字符这里不去撕哪种形式最好，只能说各有各的优劣。反正我习惯用hard tab。对于if和for语句之类的，咱们最好不要把then，do这些关键字独自写一行，这样看上去比拟丑。。。命名有规范所谓命名标准，根本蕴含上面这几点： 文件名标准，以.sh结尾，不便辨认变量名字要有含意，不要拼错对立命名格调，写shell个别用小写字母加下划线编码要对立在写脚本的时候尽量应用UTF-8编码，可能反对中文等一些奇奇怪怪的字符。不过尽管能写中文，然而在写正文以及打log的时候还是尽量英文，毕竟很多机器还是没有间接反对中文的，打进去可能会有乱码。这里还尤其须要留神一点，就是当咱们是在windows下用utf-8编码来写shell脚本的时候，肯定要留神这个utf-8是否是有BOM的。默认状况下windows判断utf-8格局是通过在文件结尾加上三个EF BB BF字节来判断的，然而在Linux中默认是无BOM的。因而如果咱们是在windows下写脚本的时候，肯定要留神将编码改成Utf-8无BOM，个别用notepad++之类的编辑器都能改。否则，在Linux下运行的时候就会辨认到结尾的三个字符，从而报一些无奈辨认命令的错。当然，对于跨平台写脚本还有一个比拟常见的问题就是换行符不同。windows默认是\r\n而unix下是\n。不过有两个小工具能够十分不便的解决这个问题：dos2unix,unix2dos。 权限记得加这一点尽管很小，然而我集体却常常遗记，不加执行权限会导致无奈间接执行，有点厌恶。。。 日志和回显日志的重要性不用多说，可能不便咱们回头纠错，在大型的我的项目里是十分重要的。 如果这个脚本是供用户间接在命令行应用的，那么咱们最好还要可能在执行时实时回显执行过程，不便用户掌控。 有时候为了进步用户体验，咱们会在回显中增加一些特效，比方色彩啊，闪动啊之类的，具体能够参考ANSI/VT100 Control sequences这篇文章的介绍。 明码要移除不要把明码硬编码在脚本里，不要把明码硬编码在脚本里，不要把明码硬编码在脚本里。 重要的事件说三遍，尤其是当脚本托管在相似Github这类平台中时。。。 太长要分行在调用某些程序的时候，参数可能会很长，这时候为了保障较好的浏览体验，咱们能够用反斜杠来分行： ./configure \–prefix=/usr \–sbin-path=/usr/sbin/nginx \–conf-path=/etc/nginx/nginx.conf \留神在反斜杠前有个空格。 编码细节标准代码有效率 在应用命令的时候要理解命令的具体做法，尤其当数据处理量大的时候，要时刻思考该命令是否会影响效率。 比方上面的两个sed命令： sed -n '1p' filesed -n '1p;1q' file他们的作用一样，都是获取文件的第一行。然而第一条命令会读取整个文件，而第二条命令只读取第一行。当文件很大的时候，仅仅是这样一条命令不一样就会造成微小的效率差别。 当然，这里只是为了举一个例子，这个例子真正正确的用法应该是应用head -n1 file命令。。。 勤用双引号简直所有的大佬都举荐在应用”$”来获取变量的时候最好加上双引号。 不加上双引号在很多状况下都会造成很大的麻烦，为什么呢？举一个例子： #!/bin/sh#已知以后文件夹有一个a.sh的文件var="*.sh"echo $varecho "$var"他的运行后果如下： a.sh*.sh为啥会这样呢？其实能够解释为他执行了上面的命令： echo *.shecho "*.sh"在很多状况下，在将变量作为参数的时候，肯定要留神下面这一点，认真领会其中的差别。下面只是一个十分小的例子，理论利用的时候因为这个细节导致的问题切实是太多了。。。 巧用main函数咱们晓得，像java，C这样的编译型语言都会有一个函数入口，这种构造使得代码可读性很强，咱们晓得哪些间接执行，那些是函数。然而脚本不一样，脚本属于解释性语言，从第一行间接执行到最初一行，如果在这当中命令与函数糅杂在一起，那就十分难读了。 用python的敌人都晓得，一个合乎规范的python脚本大体上至多是这样的： #!/usr/bin/env pythondef func1():     pass def func2():     pass if __name__=='__main__':     func1()     func2()他用一个很奇妙的办法实现了咱们习惯的main函数，使得代码可读性更强。 在shell中，咱们也有相似的小技巧: #!/usr/bin/env bash func1(){ #do sth } func2(){ #do sth } main(){ func1 func2 } main "$@"咱们能够采纳这种写法，同样实现相似的main函数，使得脚本的结构化水平更好。 ...

作者：Myths链接：https://blog.mythsman.com/201...前言因为工作须要，最近从新开始收拾shell脚本。尽管绝大部分命令本人平时也常常应用，然而在写成脚本的时候总感觉写的很难看。而且当我在看其他人写的脚本的时候，总感觉难以浏览。毕竟shell脚本这个货色不算是正经的编程语言，他更像是一个工具，用来杂糅不同的程序供咱们调用。 因而很多人在写的时候也是想到哪里写到哪里，基本上都像是一段超长的main函数，不忍直视。同时，因为历史起因，shell有很多不同的版本，而且也有很多有雷同性能的命令须要咱们进行取舍，以至于代码的标准很难对立。 思考到下面的这些起因，我查阅了一些相干的文档，发现这些问题其实很多人都思考过，而且  也造成了一些不错的文章，然而还是有点零散。因而我就在这里把这些文章略微整顿了一下，作为当前我本人写脚本的技术规范。 代码格调标准结尾有“蛇棒” 所谓shebang其实就是在很多脚本的第一行呈现的以#!结尾的正文，他指明了当咱们没有指定解释器的时候默认的解释器，个别可能是上面这样： #!/bin/bash当然，解释器有很多种，除了bash之外，咱们能够用上面的命令查看本机反对的解释器: $ cat /etc/shells#/etc/shells: valid login shells/bin/sh/bin/dash/bin/bash/bin/rbash/usr/bin/screen当咱们间接应用./a.sh来执行这个脚本的时候，如果没有shebang，那么它就会默认用$SHELL指定的解释器，否则就会用shebang指定的解释器。 这种形式是咱们举荐的应用形式。 代码有正文正文，显然是一个常识，不过这里还是要再强调一下，这个在shell脚本里尤为重要。因为很多单行的shell命令不是那么浅显易懂，没有正文的话在保护起来会让人尤其的头大。 正文的意义不仅在于解释用处，而在于通知咱们注意事项，就像是一个README。 具体的来说，对于shell脚本，正文个别包含上面几个局部： shebang脚本的参数脚本的用处脚本的注意事项脚本的写作工夫，作者，版权等各个函数前的阐明正文一些较简单的单行命令正文参数要标准这一点很重要，当咱们的脚本须要承受参数的时候，咱们肯定要先判断参数是否合乎标准，并给出适合的回显，不便使用者理解参数的应用。 起码，起码，咱们至多得判断下参数的个数吧： if [[ $# != 2 ]];then     echo "Parameter incorrect."     exit 1fi变量和魔数个别状况下咱们会将一些重要的环境变量定义在结尾，确保这些变量的存在。 source /etc/profileexport PATH=”/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/apps/bin/”这种定义形式有一个很常见的用处，最典型的利用就是，当咱们本地装置了很多java版本时，咱们可能须要指定一个java来用。那么这时咱们就会在脚本结尾从新定义JAVA_HOME以及PATH变量来进行管制。同时，一段好的代码通常是不会有很多硬编码在代码里的“魔数”的。如果肯定要有，通常是用一个变量的模式定义在结尾，而后调用的时候间接调用这个变量，这样不便日后的批改。 缩进有规矩对于shell脚本，缩进是个大问题。因为很多须要缩进的中央(比方if,for语句)都不长，所有很多人都懒得去缩进，而且很多人不习惯用函数，导致缩进性能被弱化。 其实正确的缩进是很重要的，尤其是在写函数的时候，否则咱们在浏览的时候很容易把函数体跟间接执行的命令搞混。 常见的缩进办法次要有”soft tab”和”hard tab”两种。 所谓soft tab就是应用n个空格进行缩进(n通常是2或4)所谓hard tab当然就是指实在的\t字符这里不去撕哪种形式最好，只能说各有各的优劣。反正我习惯用hard tab。对于if和for语句之类的，咱们最好不要把then，do这些关键字独自写一行，这样看上去比拟丑。。。命名有规范所谓命名标准，根本蕴含上面这几点： 文件名标准，以.sh结尾，不便辨认变量名字要有含意，不要拼错对立命名格调，写shell个别用小写字母加下划线编码要对立在写脚本的时候尽量应用UTF-8编码，可能反对中文等一些奇奇怪怪的字符。不过尽管能写中文，然而在写正文以及打log的时候还是尽量英文，毕竟很多机器还是没有间接反对中文的，打进去可能会有乱码。这里还尤其须要留神一点，就是当咱们是在windows下用utf-8编码来写shell脚本的时候，肯定要留神这个utf-8是否是有BOM的。默认状况下windows判断utf-8格局是通过在文件结尾加上三个EF BB BF字节来判断的，然而在Linux中默认是无BOM的。因而如果咱们是在windows下写脚本的时候，肯定要留神将编码改成Utf-8无BOM，个别用notepad++之类的编辑器都能改。否则，在Linux下运行的时候就会辨认到结尾的三个字符，从而报一些无奈辨认命令的错。当然，对于跨平台写脚本还有一个比拟常见的问题就是换行符不同。windows默认是\r\n而unix下是\n。不过有两个小工具能够十分不便的解决这个问题：dos2unix,unix2dos。 权限记得加这一点尽管很小，然而我集体却常常遗记，不加执行权限会导致无奈间接执行，有点厌恶。。。 日志和回显日志的重要性不用多说，可能不便咱们回头纠错，在大型的我的项目里是十分重要的。 如果这个脚本是供用户间接在命令行应用的，那么咱们最好还要可能在执行时实时回显执行过程，不便用户掌控。 有时候为了进步用户体验，咱们会在回显中增加一些特效，比方色彩啊，闪动啊之类的，具体能够参考ANSI/VT100 Control sequences这篇文章的介绍。 明码要移除不要把明码硬编码在脚本里，不要把明码硬编码在脚本里，不要把明码硬编码在脚本里。 重要的事件说三遍，尤其是当脚本托管在相似Github这类平台中时。。。 太长要分行在调用某些程序的时候，参数可能会很长，这时候为了保障较好的浏览体验，咱们能够用反斜杠来分行： ./configure \–prefix=/usr \–sbin-path=/usr/sbin/nginx \–conf-path=/etc/nginx/nginx.conf \留神在反斜杠前有个空格。 编码细节标准代码有效率 在应用命令的时候要理解命令的具体做法，尤其当数据处理量大的时候，要时刻思考该命令是否会影响效率。 比方上面的两个sed命令： sed -n '1p' filesed -n '1p;1q' file他们的作用一样，都是获取文件的第一行。然而第一条命令会读取整个文件，而第二条命令只读取第一行。当文件很大的时候，仅仅是这样一条命令不一样就会造成微小的效率差别。 当然，这里只是为了举一个例子，这个例子真正正确的用法应该是应用head -n1 file命令。。。 勤用双引号简直所有的大佬都举荐在应用”$”来获取变量的时候最好加上双引号。 不加上双引号在很多状况下都会造成很大的麻烦，为什么呢？举一个例子： #!/bin/sh#已知以后文件夹有一个a.sh的文件var="*.sh"echo $varecho "$var"他的运行后果如下： a.sh*.sh为啥会这样呢？其实能够解释为他执行了上面的命令： echo *.shecho "*.sh"在很多状况下，在将变量作为参数的时候，肯定要留神下面这一点，认真领会其中的差别。下面只是一个十分小的例子，理论利用的时候因为这个细节导致的问题切实是太多了。。。 巧用main函数咱们晓得，像java，C这样的编译型语言都会有一个函数入口，这种构造使得代码可读性很强，咱们晓得哪些间接执行，那些是函数。然而脚本不一样，脚本属于解释性语言，从第一行间接执行到最初一行，如果在这当中命令与函数糅杂在一起，那就十分难读了。 用python的敌人都晓得，一个合乎规范的python脚本大体上至多是这样的： #!/usr/bin/env pythondef func1():     pass def func2():     pass if __name__=='__main__':     func1()     func2()他用一个很奇妙的办法实现了咱们习惯的main函数，使得代码可读性更强。 在shell中，咱们也有相似的小技巧: #!/usr/bin/env bash func1(){ #do sth } func2(){ #do sth } main(){ func1 func2 } main "$@"咱们能够采纳这种写法，同样实现相似的main函数，使得脚本的结构化水平更好。 ...

运维人 为每一次告警而 “心动”，换来 7x24 的稳固； 业务失常运行的护航者，石破天惊的幕后英雄。 明天 7月24日 运维人的节日 想对所有运维人说声“辛苦啦” 借此机会 咱们联结博文视点为大家送福利啦 以下是本次的福利sh 《SRE：Google运维解密》 在本书中，Google SRE的要害成员解释了他们是如何对软件进行生命周期的整体性关注的，以及为什么这样做可能帮忙Google胜利地构建、部署、监控和运维世界上现存最大的软件系统。通过浏览，读者能够学习到Google工程师在进步零碎部署规模、改良可靠性和资源利用效率方面的指导思想与具体实际——这些都是能够立刻间接利用的贵重教训。 《企业数字化基石阿里巴巴云计算基础设施实际》 本书将具体地论述阿里巴巴在基础设施上的实际细节及先进技术，包含数据中心、网络、服务器、计算硬件、存储硬件，以及智能化经营与自动化运维等内容。 《数据中台架构——企业数据化最佳实际》 本书对企业数据化建设的指标、内容及定位做了绝对残缺的阐述，具体地论述了数据中台的定义、内容及如何撑持企业数据化整体建设，同时也介绍了数据中台在企业中的落地步骤、丰盛的数据利用场景与实际效果。本书是企业数据化建设的实用参考书。 《Kubernetes 网络权威指南根底、原理与实际》 本书是是容器与Kubernetes网络的根底和进阶书籍，旨在让更多人理解和学习云原生时代的底层网络模型与实现机制，领导企业在落地云原生时的网络计划选型。 《Kubernetes权威指南：从Docker到Kubernetes实际全接触（第4版）》 本书从架构师、开发人员和运维人员的角度，论述了Kubernetes的基本概念、实际指南、外围原理、开发领导、运维指南、新个性演进等内容，图文并茂、内容丰盛、由浅入深、解说全面；并围绕在生产环境中可能呈现的问题，给出了大量的典型案例，比方平安配置计划、网络计划、共享存储计划、高可用计划及Trouble Shooting技巧等，有很强的实战指导意义。 ☆ 福利工夫 ☆看完下面的书单，有没有见到感兴趣的书呢？感兴趣的话，就送给你！ 搜寻并关注“vivo互联网互联网技术”公众号在推文《724一起聊聊运维人的故事，赢取技术书籍》下留言写下：#你的运维故事#或#你想对运维人说的话#7月29日，咱们将将依据留言的点赞排名前5名的=侥幸读者，向每位中奖者送出本文举荐的任意一本书（哪一本由你说了算）。 技术书籍合作伙伴 快扫描图片中的二维码参加赠书流动吧。

运维人 为每一次告警而 “心动”，换来 7x24 的稳固； 业务失常运行的护航者，石破天惊的幕后英雄。 明天 7月24日 运维人的节日 想对所有运维人说声“辛苦啦” 借此机会 咱们联结博文视点为大家送福利啦 以下是本次的福利sh 《SRE：Google运维解密》 在本书中，Google SRE的要害成员解释了他们是如何对软件进行生命周期的整体性关注的，以及为什么这样做可能帮忙Google胜利地构建、部署、监控和运维世界上现存最大的软件系统。通过浏览，读者能够学习到Google工程师在进步零碎部署规模、改良可靠性和资源利用效率方面的指导思想与具体实际——这些都是能够立刻间接利用的贵重教训。 《企业数字化基石阿里巴巴云计算基础设施实际》 本书将具体地论述阿里巴巴在基础设施上的实际细节及先进技术，包含数据中心、网络、服务器、计算硬件、存储硬件，以及智能化经营与自动化运维等内容。 《数据中台架构——企业数据化最佳实际》 本书对企业数据化建设的指标、内容及定位做了绝对残缺的阐述，具体地论述了数据中台的定义、内容及如何撑持企业数据化整体建设，同时也介绍了数据中台在企业中的落地步骤、丰盛的数据利用场景与实际效果。本书是企业数据化建设的实用参考书。 《Kubernetes 网络权威指南根底、原理与实际》 本书是是容器与Kubernetes网络的根底和进阶书籍，旨在让更多人理解和学习云原生时代的底层网络模型与实现机制，领导企业在落地云原生时的网络计划选型。 《Kubernetes权威指南：从Docker到Kubernetes实际全接触（第4版）》 本书从架构师、开发人员和运维人员的角度，论述了Kubernetes的基本概念、实际指南、外围原理、开发领导、运维指南、新个性演进等内容，图文并茂、内容丰盛、由浅入深、解说全面；并围绕在生产环境中可能呈现的问题，给出了大量的典型案例，比方平安配置计划、网络计划、共享存储计划、高可用计划及Trouble Shooting技巧等，有很强的实战指导意义。 ☆ 福利工夫 ☆看完下面的书单，有没有见到感兴趣的书呢？感兴趣的话，就送给你！ 搜寻并关注“vivo互联网互联网技术”公众号在推文《724一起聊聊运维人的故事，赢取技术书籍》下留言写下：#你的运维故事#或#你想对运维人说的话#7月29日，咱们将将依据留言的点赞排名前5名的=侥幸读者，向每位中奖者送出本文举荐的任意一本书（哪一本由你说了算）。 技术书籍合作伙伴 快扫描图片中的二维码参加赠书流动吧。

企业上云，是少数互联网企业的必经之路，在国内，阿里云占居了少数的市场份额，所以，对于阿里云ECS主机的运维也成了少数人的首要任务。 那么，你必定会遇到以下的问题： grub.conf 文件内容被清空了怎么办？Linux虚机Load高的“首恶”是什么？ifdown ifup命令失落如何解决？为什么明明内存很短缺然而Java程序仍申请不到内存？这些问题你能疾速无效的解决吗？ 如果你的答案是：“NO！” 这本《ECS运维指南之Linux系统诊断》电子书，将会帮忙你疾速解决这些难题。 本文作者：杨牧原（花名牧原），阿里云技术专家，多年操作系统和利用调试教训，实践功底深厚，实践经验丰盛。目前专一 Linux 性能调优，容器集群和零碎网络。 《ECS运维指南之Linux系统诊断》为何值得被下载珍藏？ 阿里技术专家精心之作多年云上ECS运维教训出现最佳优化解决方案18个高频问题案例解析 强烈推荐大家：下载浏览 正确下载姿态：点击分享到朋友圈，并点在看反对，而后扫下方二维辨认后回复关键词  阿里云ECS 即可收费支付 （辨认二维码，收费支付电子书）

开发测试治理和运行治理是 DevOps 平台实际中常见的两大问题。前者个别体现为开发效率低、版本品质差、环境交付慢、无对立工具设置和研发运维过程管控有余等，须要通过 DevOps 平台进行流程化治理。另一方面，随着云计算的倒退，企业须要治理和保护的基础设施规模扩充，在混合云、多地区等各种异构网络环境下须要一套调度零碎来治理和管制各类资源，解决运行治理问题。 7 月 2 日，京东智联云和英特尔联结举办了「DevOps 平台高可用架构与实际」线上公开课，来自京东智联云的云产品研发部架构师陈尧，和来自博云的售前解决方案架构师伞亚朋，别离介绍了大规模任务调度零碎的架构设计与 DevOps 平台的流程化治理办法。 以下内容整顿自两位老师的分享。 企业上线 DevOps 平台，实质上是为了以较低的老本高效解决运维需要。同样，任务调度零碎的初衷也是为了管制老本、提高效率。当企业的线上业务规模逐步扩充，单纯靠减少人手来解决系统升级、保护、部署、监控等事务的老本是很难接受的，这时就轮到自动化的任务调度零碎退场了。 在实践中，业务规模较大的企业开发任务调度零碎时会面临很多问题：机器规模宏大，散布地区宽泛，甚至逾越寰球；资源品种繁多（物理机/虚拟机/容器等）；私有云/公有云环境并存；操作系统多样化；VPC/子网等网络问题等等。要设计出可能从容应对这些挑战的任务调度零碎绝非易事，因而咱们就须要参考行业中已有的成熟教训和实际。 自 2006 年熊猫烧香病毒事件后，整个黑客产业链开始将重心转向了通过 DDoS 等攻打伎俩获取不法收益上。随着攻打技术一直倒退，现在一次大规模的 DDoS 的流量可达数以 Tbps 的惊人程度。 DDoS 的实质是黑客管制互联网上的少量机器向指标发送流量。这种技术要克服的阻碍与任务调度零碎有诸多类似点，例如规模微小、网络不稳固、机器所在区域扩散、零碎版本泛滥等等。 为了解决这些问题，黑客抉择的技术计划就是基于 IM 聊天协定的零碎架构。作为管制方的黑客实际上是 IM 网络中的一个节点，被管制的机器等效于客户端，前者向后者发送音讯，即可达成管制的目标。 在 DDoS 攻打流动中，黑客广泛应用的协定是 IRC： 在 IRC 模型中，攻击者本人建一个 master，再加一个管制服务器来管制僵尸网络中的节点；攻击者通过 master 连贯到管制服务器上即可操纵僵尸节点发动攻打。须要留神的是 IRC 是匿名聊天协定，零碎不关怀连上管制服务器的是什么身份，只有能连上就能够施行管制。 但在典型的聊天利用场景中，更适合的抉择是基于登录账号体系的 XMPP 协定： 在 XMPP 中，通信的各方都有本人的账号/身份，进而就能够倒退出权限管制体系。如上图所示，XMPP 是对等互联网络，网络中的各节点都能够相互通信。因为各节点都有本人的身份，当某个节点收到其余节点发来的要求时，就能够依据对方的身份来抉择是否听从。 正因如此，XMPP 更适宜作为任务调度零碎的主协定。参照黑客应用的 IRC 网络模型，很容易得出基于 XMPP 模式的任务调度模型： ...

TASKCTL是成都塔斯克信息技术有限公司专为批量作业调度自动化打造的一款麻利调度工具。可为批量作业自动化调度者提供简略的办法来治理各类简单作业的调度和监控治理。TASKCTL通过将企业外部简单的作业调度依赖关系，进行灵便的对立编排和治理，带来前所未有的简略性。TASKCTL采纳全内存计算，基于全事件技术驱动，可简略、疾速地对作业进行定义、编排和执行，并生成优化调度执行倡议，从而负载平衡执行作业调度。 TASKCTL作为麻利批量调度的开拓者，产品设计从一开始就专门为整洁的体验而设计，并提供丰盛、直观的用户界面，以简化常见的作业调度执行编排流程。 TASKCTL产品性能架构图 弱小的外围自动化调度能力TASKCTL提供了弱小的外围自动化调度能力。 ●    作业关系调度管制：对作业（流）实现作业（流）的依赖关系调度、作业并行调度、作业间互斥调度。 ●    容错策略管制：对作业（流）实现谬误主动重做、谬误主动疏忽等管制 ●    打算排程：反对天然日历排程、逻辑日历排程等设置。 ●    流程启动触发：提供事件触发、文件触发、定时频度触发、自定义工夫触发、自定义条件触发等管制。 ●    其余：反对返回值管制、跳转管制、条件分支、参数管制、变量主动设置、作业输入输出传递、工夫窗口管制、并发度管制、物理资源阀值管制、逻辑资源阀值管制、优先级管制、循环管制、断点续做、负载平衡调度。 丰盛的利用及用户治理TASKCTL提供了Windows图形客户端（C/S）、类Unix或Linux零碎的字符客户端等多种利用渠道界面，可满足不同水平的作业批量调度开发人员、运维人员及监控管理人员的应用，并提供了丰盛的利用治理性能。 ●    人工干预性能（手工保障）：反对人工执行任意作业、人工执行指定分支、作业重做、正执行作业人工中断、断点设置、设置作业有效、强制通过、执行条件人工疏忽、并行度实时人工调整、资源阀值人工调整、优先级实时人工调整、控制变量人工批改、追数调度等人工干预性能。 ●    统计分析：提供排程分布图、零碎运行工夫窗口分布图、作业运行时序图、作业耗时排序图、作业运行关联剖析、作业出错率统计分析图等展现。 ●    零碎平台治理：提供节点治理、用户及权限治理、迁徙部署、信息备份、平台日志治理、版本治理等平台治理性能。 ●    作业(流)定义设计性能：提供作业流程嵌套设计、信息变量化设计、设计信息自动检测、单作业对话框形式定义、流程图设计能力、单作业图形拖拽设计、多作业批量化立体文件形式设计、批量设计在线化、批量设计与图形化设计实时互动等作业（流）设计性能。 ●    全方位监控治理：提供流程图实时动静监控、多维度的统计列表监控、短信实时监控、邮件形式非实时告诉、启动文件达到监控、调度体系拓扑图监控、资源监控等性能。 ●    信息查问：提供历史调度信息查问、作业日志查问、作业信息查问、变量信息查问、人工操作记录查问性能。 敏捷性设计TASKCTL作为麻利调度的开拓者，从产品设计之初就立足于简洁应用，麻利调度。 ●    架构的灵活性：提供调度服务+执行代理部署构造、散布独立调度、对立运维监控利用架构。 ●   界面敌对性：提供分钟级的软件装置和部署，流程图无穿插的敌对展现、流程拖拽设计、秒级疾速全局搜寻和定位、清新简洁操作界面。 ●    产品开放性：提供跨平台、跨零碎、宽泛的作业类型反对，提供作业类型对立扩大性能，并提供调度外围各种利用管制接口和外围各种数据的开放性。 ●    产品高性能：超低的调度服务节点资源耗费和调度代理节点资源耗费大幅节俭了宿主机和代理的资源运行。高效的调度效率（吞吐量）40个/秒 ，可大幅晋升整体调度品质，并可轻松撑持10万+级作业调度利用。 ●    低依赖：不依赖任何第三方中间件技术，全内存数据拜访大大降低了软硬件的依赖性。 ●    高牢靠：反对调度服务节点、调度执行代理节点的高牢靠。 ●   信息安全：提供加密的网络通讯平安、强明码控制策略、和人工操作记录审计性能。 生产级的简便性TASKCTL麻利调度产品简洁清新的操作界面和便当的购买形式，大大节俭了用户的洽购和学习老本。 ●    产品购买：提供TASKCTL官网和微信公众号两种渠道的在线交易购买服务，用户可通过租赁的形式购买TASKCTL产品及服务，可实现分钟级的软件购买和软件注册。租赁购买的灵便形式大大节俭了客户的洽购老本。 ●    产品材料：丰盛的产品装置手册、使用手册、配置手册、二次开发手册、外围架构技术原理等材料，可疾速进步应用人员对产品的相熟度。 ●    知识库：丰盛的知识库，积攒了TASKCTL上百家级客户的应用问题和纳闷解答，并提供微信公众号和官网的同步查阅和搜寻。 写在最初2020年疫情席卷寰球，更是对整个市场经济造成了重大影响，导致很多中小型企业业务链碰壁，大型企业经费资金吃紧，轮班制导致公司运维人员工作量大幅减少；塔斯克信息技术公司经领导钻研决定为了履行社会责任，踊跃回报社会，帮忙在此疫情期间受影响的企业缩小运维资金收入、晋升工作效率、保障后盾数据安全，工作需要场景可能利用到的ETL批量作业调度工具的，将在此疫情期间让你白嫖收费应用价值总额约10万级的TASKCTL

一. 背景在蚂蚁团体智能监控畛域，时序异样检测是极重要一环，异样检测落地中，业务方参考业界规范输入 Metrics 指标数据，监控不同业务、利用、接口、集群的各项指标，蕴含 Metrics 指标（总量、失败量、耗时等）和零碎服务指标（CPU、MEM、DISK、JVM、IO 等）。晚期的时序异样检测是由 SRE 联合长期运维教训通过配置专家规定来实现，随着 AI 技术的遍及，异样检测逐渐 AI 化，在事实场景中，AI 算法经常面临如下挑战： 每日不同时段，业务时序曲线出现不同的部分均值/方差个性；非凡日期如大型节假日、大促日，时序数据与日常差别微小，甚至与今年同期也存在不小差别；每日或距离几日固定时间段中随机时刻产生的偏定时事件；海量监控业务，很难针对独自指标一一建模；下图是一组耗时指标时序数据，按分钟采样，存在显著日周期性，在每日不同时段，均值/方差差别显著；凭专家教训按时间段强行设置阈值，难度大准确度低；应用回归模型拟合数据分布，精度高，但难以泛用到其余指标。 图1 耗时时序曲线 本文基于 CNN 神经网络方向进行了一些摸索，在保障检测准确率与召回率的同时，也能保障模型有较好的泛用性。 二. 算法调研下图整顿出局部时序数据异样检测波及算法，这里不一一详述，有趣味自行查问相干算法原理。 图2 异样检测相干算法 从是否依赖标注训练样本的角度看，算法次要分为有监督和无监督两个方向（半监督这里就不介绍了）。无监督算法免去了标注样本消耗的大量人力，适宜冷启动，但最终还需算法开发人员继续调参去寻找最优分类决策立体，在调参过程中还需兼顾不同监控业务的本身特点；有监督算法则相同，但往往模型可解释性较差，日常运维中用户会常常询问：为啥告警/为啥没告警，运维人员这时可能会风中凌乱，同时不同业务 owner 对异样评判的规范是存在差别的，如果不能在异样评判的规范上达成统一，应用有监督算法往往需为不同的评判规范保护多套样本集。 CNN 的卷积层在提取异样波形特色上有显著的劣势，复杂度适合的全连贯层实践上也可拟合出所有的非线性关系；还有一点，网络结构的设计是一件灵便的工作，算法工程师有较大的施展空间，而非仅仅波及调参。 三. 算法原理此章从特色工程，样本加强，神经网络设计三局部介绍基于 CNN 模型计划，还是以耗时指标为例进行阐明。 3.1 特色工程不同样本的均值/方差/趋势差别显著，须要将原始时序数据映射到对立量纲的空间。 模型原始输出为5组输出通道： 当日数据： 前 n 分钟到以后预测工夫点时序数据；同比数据（前1天）：1天前以后时刻为参考点，前 n 分钟到后 m 分钟内时序数据；同比数据（前2天）：2天前以后时刻为参考点，前 n 分钟到后 m 分钟内时序数据；同比数据（前7天）：7天前以后时刻为参考点，前 n 分钟到后 m 分钟内时序数据；同比数据（前14天）：14天前以后时刻为参考点，前 n 分钟到后 m 分钟内时序数据；同比数据时段抉择前 n 分钟到后 m 分钟，是因为某些周期性事件并非在一个固定工夫点产生，而是在一个固定时间段中随机取值。在作者实际中 n=60，m=30。 次要解决问题： 打消了不同日期时序数据水位差别带来的影响；打消了不同日期时序数据抖动幅度差别带来的影响；打消了不同指标的值域范畴差别带来的影响；整个数据处理流程按如下几环节程序进行。 3.1.1 方差标准化方差体现了时序数据在统计时段内的抖动激烈水平，在实在样本中，当日方差与往期同比时段方差可能存在较大差别，如果不做标准化解决，会导致抖动激烈的时序数据很容易产生误报。 ...

简介： windows系统诊断，云运维工程师不可错过的匠心之作 无论你是老手还是新手，你的Windows零碎都会遇到不容易诊断的问题。而当产生这种状况时，你会怎么做？心愿本书能够在零碎呈现问题然而又不晓得到底产生了什么以及问题呈现在哪里时，为大家提供解决思路和办法，高效的解决问题。 点击收费下载《ECS运维指南 之 windows系统诊断》 本书是《ECS运维指南 之 Linux系统诊断》系列篇，贯彻了实践与实际相结合的方针。本书联合阿里云工程师多年云上ECS运维教训，从实战角度解说windows，实例丰盛，容易了解，内容实用，适宜学习。 《ECS运维指南之Windows系统诊断》的作者，阿里云工程师棋玉，具备多年windows零碎排查及阿里云服务器排查教训，目前专一服务器零碎内核、性能调优畛域。 也可在PC端关上 https://developer.aliyun.com/topic/download?id=710 下载 —精彩章节领先看— 本书内容实用，书中透彻解析33个windows常见问题案例，能够很好地为读者的实战之路提供360°领导。 目录 windows启动失败罕用排查计划别离从两个不同版本的零碎来教你如何解决“windows启动失败”的问题 装置补丁后服务器启动卡住两个案例透彻排查装置补丁后服务器启动卡住的状况 重启卡在“正在利用计算机设置”？6步排查搞定重启卡在“正在利用计算机设置”？六步排查搞定 Windows 控制台登录不能切换用户控制台登录无奈切换用户？三个步骤帮你搞定 启动报错“An operating system wasn't found”启动报错“An operating system wasn't found”时须要留神的四个点 windows重置明码不失效针对windows重置明码不失效问题的具体排查 启动报错“No bootable device”三个步骤排查启动报错“No bootable device” 激活罕用排查计划本文分享激活罕用排查计划中须要留神的四个点 window机器ping不通KMS 服务器三个点理解window机器ping 不通KMS 服务器的问题 windows激活报错 0xC004F074四个步骤轻松解决windows激活报错 0xC004F074的问题 windows激活报错0x80070020或0x80041010深度分析windows激活报错0x80070020或0x80041010的问题 windows近程问题的3个排查计划windows近程问题的3个排查计划 windows网络状态显示X，看不到网卡信息“windows网络状态显示X”不再是难题 Windows网卡驱动失落，手动装置驱动Windows网卡驱动失落？教你如何手动装置驱动 windows更新罕用的5个排查计划分享windows更新罕用的5个排查计划 查找更新时报错 ？2个计划解决两个计划解决查找更新时报错的问题 “此更新不适用于你的计算机” 的3个排查办法此更新不适用于你的计算机” 的三个排查办法大放送 更新装置报错的3个实战剖析更新装置报错的3个实战剖析 服务启动失败？2步轻松搞定服务启动失败？2步轻松搞定 服务启动报错“不能在本地计算机启动”带你揭秘服务启动报错“不能在本地计算机启动”时该如何解决 服务启动失败“零碎找不到指定文件”服务启动失败“零碎找不到指定文件”的案例分享 如何手动复原服务超具体！教你如何手动复原服务 占用内存高-分页数/未分页六个点透彻排查分页数/未分页 占用内存高的问题 内存占用高-AWEAWE占用内存高？浏览本文教你如何解决 explorer.exe 占用cpu或者内存高三个方面动手，解决explorer.exe 占用cpu或者内存高的问题 ...

前言： 美方：Control-M ( www.bmc.com)中方：TASKCTL ( www.taskctl.com ) ETL调度工具中美PK ( TASKCTL VS Control-M)Control-MTaskCtl而国内，在泛滥的软件中抉择TASKCTL，我仿佛没有任何犹豫。该软件尽管没什么名气，但它清爽的界面、独特设计、用户体验让我印象太粗浅。我想，假以时日，TASKCTL肯定会有它的江湖位置。好了，赞美的话还是少说，评估技术要主观，咱们还是站在主观的立场来一场中美PK! 先说说PK办法：这两款软件都声称企业级调度软件，咱们就先从软件企业级特色方面PK，随后从软件性能点进行PK，最初，PK最要害的东东-用户体验！ 企业级特色体验PK说实话，什么是调度的企业级特色，我无奈定义，但至多应该有以下几个方面：网络撑持能力、跨平台能力、稳定性、大规模数据撑持能力、数据集中管理、对立利用门户等。我权且就从这几个方面比拟。 1. 网络撑持能力，这次要由软件外围网络架构决定，这两款软件都别离通过EM节点、Server节点、代理节点并以多级的形式进行网络管制； 2. 跨平台能力，TASKCTL只反对unixlinux环境，而Control-M反对各种支流操作系统； 3. 稳定性，这个很无聊，但又不能回避。稳定性不是软件测试就能够搞定的，最终还需理论环境短暂的考验。这方面，TASKCTL是不能和Control-M相比的。 4. 大规模数据撑持能力，尽管两款软件都是声称能够反对10万级的工作，然而，这种能力不是吹出来的，还得须要理论来验证。Control-M一方面以数据库存储数据，另一方面它有理论案例（中国建行)；而TASKCTL作为一支新秀，这种大数据案例方面，必定没有。另外，从技术的角度，TASKCTL无数据库，面临大规模数据撑持肯定会遇到相应的技术艰难。 5. 数据集中管理，软件总是离不开数据，调度软件须要治理大量的流程等设计信息。作为一个企业级平台，流程信息的集中管理很必要。Control-M以数据存储数据，而且集中管理；TASKCTL，数据以文件形式存储，仿佛也没集中管理，流程信息存储在不同的调度服务节点之上。 6.对立利用门户，这两款软件都是能够单点治理多个调度服务器，企业不同我的项目均可通过对立客户端进行治理利用。 PK论断：从企业级特色的角度，Control-M具备显著劣势。Control-M是一款真正企业级技术平台，而TASKCTL最多只能称准企业级技术平台。如果说Control-M是重量级的调度平台，那么Taskctl就只能是轻量级的调度平台。 性能点PK总体来说，对这两款软件，我认为从性能的角度，不论是外围调度性能，利用性能，扩大性能，它们都并驾齐驱。只是实现形式有些不一样而已。咱们以外围调度性能举例。调度外围性能次要是由工作执行条件判断能力所决定。Control-M条件判断次要通过资源条件、执行打算打算、自定义条件(Condition）三个方面来确定；而TASKCTL通过资源条件、执行打算、构造条件(串并构造、循环构造等)、容错条件、依赖、互斥、自定义条件(Condition）等多方面来决定。两个软件共同点，都是通过自定义条件来扩大及欠缺条件判断体系；而不同点，Control-M更为形象，TASKCTL更具体。 如果非要说性能的区别，我认为是Control-M具备文件传输性能(但该性能曾经超出调度的领域)，TASKCTL没有；TASKCTL有流程调试性能，Control-M没有。 PK论断：如果只站在ETL调度及其利用性能点的角度，这两款软件各有千秋，PK后果平分秋色。 用户体验PK说到用户体验，我毫不犹豫投TASKCTL一票。该软件独特设计带来独特的用户体验是Control-M无奈相比的。 用户体验，是软件设计的核心理念，一款软件不仅仅是性能的残缺，敌对的用户体验才是王道。我记得我已经的我的项目领导就十分强调用户体验，性能是性能，体验是体验。他常常拉UI工程师、美工一起探讨用户体验的问题。很久以来，我深受该领导的影响，认为体验的重点就在于UI，好的美工，好的布局，好的操作流程，我想很多敌人也批准我的观点。但接触TASKCTL后，我的认识却有了很大的改观，发现自己的意识太过局限，好的体验不仅仅在界面那一亩三分地，而更多来自好的架构，好的机制，为了好的体验，不惜翻新，甚至敢于冲破。但冲破翻新是要付出肯定的代价，而且体验于翻新不能轻重倒置， 就像taskctl的官方网站所说，翻新不是目标，而更好的利用才是基本。 那么，咱们就来看TASKCTL怎么通过一系列的翻新设计优化它的用户体验。 关注焦点：TASKCTL的翻新、要害用户场景、与Control-M的比照。 先说TASKCTL几个要害的翻新1. 无数据设计，无数据技术并不陈腐，但在业余调度技术平台畛域，该软件是惟一。 2. 流程的开发理念，流程设计的核心内容就是定义各种调度的指标工作，以及各种工作的控制策略，比方依赖、并行、执行打算等。传统采纳配置形式，这种形式的实质就是通过设计各种数据表存储设计的各种信息，比方工作根本信息，管制信息等，利用时通过设计各种对话框来填充这些信息，这种形式称为配置形式。而TASKCTL采纳开发方式，将流程的信息代码化，像开发程序一样开发流程。利用时通过相似VS一样的集成环境来设计流程。 3. 客户端脱机利用模式，不管国内业余调度软件还是国外业余Control-M，客户端的利用必须连贯服务端；而TASKCTL客户端能够脱机利用，即无需连贯服务端，就是实现除实在调度以外的所有操作体验。 4. 插件机制，业余调度平台反对不同类型的工作是根本的。Control-M通过行命令进行扩大，而TASKCTL明确提出驱动插件机制，通过不同驱动插件来扩大不同工作的反对。 5. 多种形式的利用零碎，TASKCTL的调度利用，不仅有Admin、Designer、Monitor三个图形客户端软件，而且还有与之匹配的三个领取客户端软件。不管桌面客户端，还是后盾字符界面客户端，都是残缺的利用体系。Control-M尽管有后盾字符界面，但该利用体系不残缺，也不能齐全与前台桌面客户端对应。 要害利用场景用户体验肯定落地到具体利用场景才有意义，调度的最重要的利用场景包含： 1. 装置部署利用场景，装置部署是软件应用的首要场景。 2. 流程设计利用场景，对于调度利用来说，该场景可能是最次要利用场景，通过该场景，咱们通知了调度平台该干什么活、怎么干活。 3. 运行监控利用场景，不必多说，该场景是客户最关怀的，因为，咱们须要要晓得调度平台干活到底干的怎么样了。 4. 查问利用场景，咱们常常都很无聊，总是回顾过来，看看咱们已经做过些什么。 当初，咱们来看看TASKCTL的翻新在以上利用场景中,相比Control-M怎么杰出施展。 1.流程图展现成果 Control-MTaskCtl在剖析各个利用场景之前，咱们先看看流程图展现成果，流程图的好坏关系到很多利用场景。 软件的容易，是因为把握了技术，都容易实现指定的业务性能。软件的艰难，是实现了某种性能，但它并不一定实用。不论是各种耳熟能详ETL工具中的调度，还是很多业余调度平台，都具备流程图的展现。但如果说谁的流程图更实用，我认为TASKCTL的流程图最具实用性。很多软件只是停留在能画流程图的层面，而TASKCTL不仅能够画流程图，它为了好看且清爽的展现，它为了不便查问、定位、切换等操作，提供了八大技巧性能。 尽管我说的很必定，但仁者见仁，每个人都有本人的认识。不过，你一一比对TASKCTL这八大特色就会明确，而且，你肯定要记住，流程图的基本目标，不是为了画图，也不是为了设计，而是为了直观的展现，为了通过图形，疾速理解你的流程是什么‘样子‘。 Control-M图形展现，尽管有肯定技巧，但与TASKCTL相比，它的技巧仿佛还少了许多；另外，在大型图背后，TASKCTL无线条交织且规定的展现特色，是Control-M跨不过来的坎。 2.装置部署利用场景 Control-M即使您相熟，环境搭建没有半天你别想搞定。而TASKCTL无论你否相熟，按《TASKCTL老手体验》操作，10分钟搞定。TASKCTL不论是桌面客户端，还是服务端，装置简直傻瓜化，基本操作就是，下一步，y, 回车。TASKCTL装置的简洁一方面归功于软件的外围接口设计简洁以及安装包本身的设计，另一方面就要归功于无数据库设计了。 3.流程设计利用场景 在该场景的不一样的利用我认为是TASKCTL最不一样的中央。总体来说，不论是Control-M采纳对话框定义配置的形式，还是TASKCTL采纳代码设计形式，它们都能够实现流程的设计，但Control-M的形式不足肯定的理论可操作性，而Taskctl的形式岂但不便，而且还简略、快捷。 在一个调度利用中，工作是成千盈百的，试想一下，通过Control-M定义一千个工作，咱们必定会在不同对话框中来回点击保留切换，而每个工作可能又有很多属性，能够预感，这种操作使理论利用变得有些艰难。而理论利用中，很多我的项目应用Control-M时，都没采纳软件提供的配置形式，而是通过电子表格来定义。因为电子表格毕竟是立体文档，很多信息就在一个中央编辑即可，从而防止泛滥的对话框点击切换操作。采纳电子表格绝对对话框还有一个益处，就是信息搜寻定位也不便了很多。 这种景象阐明了以下几个事实：面对流程设计利用场景时，在大流程背后，Control-M实践上有残缺的实现计划，但理论却不足可操作性，我的项目宁肯采纳与之无关的电子表格，也不应用Control-M本身的计划，让Control-M的计划形同虚设。 接下来，咱们说说TASKCTL，它采纳代码形式设计流程。代码自身就是通过文原本承载，加之在代码根底上设计一个成熟的代码集成开发设计环境，使流程的设计编辑治理变得十分不便。对于集成开发环境理念，大家就十分相熟了。图形形式代码形式能够任意切换，就看集体的爱好。兴许有人认为，集成开发环境，看似很好，但代码形式，尽管易编辑，但代码的学习老本高，没配置的好了解。不错，这确实是关键问题。但惋惜的是，TASKCTL的代码只能算准代码，虽有肯定的语法特色，但总体很易懂，很易把握，我自己不到半天就能够应用了。 另外，通过TASKCTL的流程代码设计出等同性能的流程信息规模，我认为是起码的，至多比Control-M少。从TASKCTL官网材料走漏，TASKCTL的流程信息量与Control-M相比，只是Control-M的1/5，甚至更少。对于这个数字，我认为不精确，Control-M流程信息从设计的角度不好统计其规模，但我还是深信TASKCTL的是最简洁的，因为它还有代码本身的非凡机制以及插件机制来保障。至于这些机制怎么保障流程信息设计更少，更简洁，在此我不多说了，等有机会，再和大家交换。 4.监控利用场景TaskCtlControl-M对这个利用场景，除了一些不一样的操作技巧以外，我认为整体上TASKCTL并没有什么杰出亮点。但残缺的后盾客户端利用零碎，让技术人员有更多的抉择。 5.查问利用场景 对于这个场景，我认为是TASKCTL设计中最神不知、鬼不觉而又相对无意为之的。如果你是技术人员，你肯定喜爱。 这个惊喜归功于TASKCTL的脱机利用机制，也就是说你能够不依赖服务器，轻松带着你的’流程‘到处走。不管何时，你都很轻松晓得你的流程是什么样子。回家，看看，改改；白天下班，不论是办公室、会议室、劳动间，你都很不便与共事探讨探讨你的流程；来到我的项目，你能够将流程悄悄的带走。当有一天，关上TASKCTL客户端，你能够看到你已经设计的各个流程，届时，你心里肯定很骄傲吧。 这些，看似与调度无关，然而不是又很实用呢？ 那看看Control-M是否能够做到呢？我的答复是，实践上能够，但理论不可能。你只有想想，连服务端是不是很不便就晓得了。兴许除了我的项目现场能够不便连贯，其它中央，还是洗洗睡吧！ 最初想说非常感谢你能看到这里。PK归PK，论断归论断，抉择归抉择，每个人心中都有本人的抉择，我的抉择是面对超大型我的项目（10000个工作以上），ETL调度还是Control-M，而中小型我的项目，我可能要抉择TASKCTL。 欢送大家将你的认识留言在评论区与咱们一起探讨，咱们将优先选取3-5位精品留言给与收费应用taskctl 6.0 永恒权限，让你近一步亲临理解产品的功能属性同时，更是对咱们国内软件研发群体的反对与必定....

主机cmszsoaa存储空间扩容步骤：一. 变更内容存储3PAR8440_GT1划分3TB存储，调配给HPUX主机cmszsoaa。主机零碎辨认新扩容的存储磁盘，并创立磁盘别名（Oracle ASM磁盘治理时须要）。二. 变更前筹备2.1 收集相应主机存储磁盘应用状况及链路辨认状态。2.1.1 确认零碎连贯的存储ioscan -fnCdisk -N （确认划分的是3par磁盘）2.1.2 通过存储工具查看磁盘状况# 依据步骤 2.1.1 查问的后果，应用相应的存储工具查看具体信息（3parinfo/evainfo/xpinfo...）3parinfo -i |sort -k62.1.2.1 确认磁盘命名和规定：记录vv name以及以后零碎已应用的命名编号；比方vv_cmszsoaa_b_004，下一块vv从005开始 2.1.2.2 确认存储序列号，查问对应存储名称和登录形式查问《CMSZ设施清单表》，记录有治理ip以及登录账号/明码等 2.1.2.3 确认以后零碎已有磁盘单个vv的容量大小。客户个别只会提出存储空间需要总容量（或初步布局了单个盘大小和数量，不肯定正当），具体该如何拆分须要依据状况剖析。 比方：如果磁盘是oracle asm治理应用的磁盘，倡议与以前划分磁盘Raid形式以及容量大小要保持一致。 注：此处须要评估客户扩容空间合理性，1、存储残余空间是否满足扩容需要 2、须要与客户沟通3T空间具体的划分形式：1T * 3; 2.2 确认存储3PAR8440_GT1衰弱状态失常（尽量不要在存储故障状态下变更，防止减少后盾调配或blance的压力，发生意外影响）。三. 3PAR8440_GT1存储操作登录3par：ssh 3paradm@192.168.22.69 明码： 3.1 查看并确认存储数据分布形式和vv name排列序号（是否与零碎查看后果相符 参照2.1.2后果）showvv vv\_cmszsoa\*#(1、确认vv数据分布形式是TPVV模式、full模式 or TDVV模式 2、确认新vvname排序号从005开始)#备注：如果零碎无奈运行3parinfo 查看vv状况，且客户提供的主机名称与存储命令vv、host、hostset、vvset等命名信息不完全一致，须要让客户提供WWN，进一步进行确认。（比方ESXi主机）showhost # 查问wwn对应主机名 --> showvlun 查问导出（映射）到主机的vv3.2 查看并确认vv所在CPGshowcpgshowvvcpg vv\_cmszsoa\* (确认扩容主机vv以后应用的CPG）3.3 查看vv对应的vvset名字showvlun -lvm |grepshowvlun -v vv\_cmszsoa\*3.4 依据以上确认信息，划分存储vv磁盘空间，并将新vv退出到vvset中。3.4.1 创立vvcreatevv \-tpvv CPG\_SAS\_PROD\_R5 vv\_cmszsoaa\_b\_005 1Tcreatevv -tpvv CPG\_SAS\_PROD\_R5 vv\_cmszsoaa\_b\_006 1Tcreatevv -tpvv CPG\_SAS\_PROD\_R5 vv\_cmszsoaa\_b\_007 1T3.4.2 将划分的vv增加至已有的vvset中createvvset \-add vset\_cmszsoaa\_b vv\_cmszsoaa\_b\_005 vv\_cmszsoaa\_b\_006 vv\_cmszsoaa\_b\_007注：每个vv 1T，共计3个vv。 ...

概述taskctl是一款国内开源的ETL工具，纯C编写，可以在Window、Linux、Unix上运行。 说白了就是，很有必要去理解一般ETL工具必备的特性和功能，这样才更好的掌握taskctl的使用。 今天主要先描述ETL工具的通用功能。 ETL工具的功能之一：连接任何ETL工具都应该有能力连接到类型广泛的数据源和数据格式。对于最常用的关系型数据库系统，还要提供本地的连接方式（如对于Oracle的OCI），ETL应该能提供下面最基本的功能： 连接到普通关系型数据库并获取数据，如常见的Orcal、MS SQL Server、IBM DB/2、Ingres、MySQL和PostgreSQL。还有很多很多从有分隔符和固定格式的ASCII文件中获取数据从XML文件中获取数据从流行的办公软件中获取数据，如Access数据库和Excel电子表格使用FTP、SFTP、SSH方式获取数据（最好不用脚本）还能从Web Services 或 RSS中获取数据。如果还需要一些ERP系统里的数据，如Oracle E-Business Suite、SAP/R3、PeopleSoft 或 JD/Edwards，ETL工具也应该提供到这些系统的连接。还能提供http://Salesforce.com和SAP/R3...，但不是套件内，需要额外安装。对于其他ERP和财务系统的数据抽取还需要其他解决方案。当然，最通用的方法就是要求这些系统导出文本格式的数据，将文本数据作为数据源。 ETL工具的功能之二：平台独立一个ETL工具应该能在任何平台下甚至是不同平台的组合上运行。一个32位的操作系统可能在开发的初始阶段运行很好，但是当数据量越来越大时，就需要一个更强大的操作系统。另一种情况，开发一般是在Windows或 Mac机上运行的。而生产环境一般是Linux系统或集群，你的ETL解决方案应该可以无缝地在这些系统间切换。 ETL工具的功能之三：数据规模一般ETL能通过下面的3种方式来处理大数据。 并发：ETL过程能够同时处理多个数据流，以便利用现代多核的硬件架构。分区：ETL能够使用特定的分区模式，将数据分发到并发的数据流中。集群：ETL过程能够分配在多台机器上联合完成。Kettle是基于Java的解决方案，可以运行在任何安装了Java虚拟机的计算机上（包括Windows、Linux和Mac）。转换里的每个步骤都是以并发的方式来执行，并且可以执行多次，这样加快了处理速度。 Kettle在运行转换时，根据用户的设置，可以将数据以不同的方式发送到多个数据流中（有两种几本发送方式：分发和复制）。分发类似与分发扑克牌，以轮流的方式将每行数据只发给一个数据流，复制是将每行数据发给所有数据流。 为了更精确控制数据，Kettle还使用了分区模式，通过分区可以将同一特征的数据发送到同一个数据流。这里的分区只是概念上类似于数据库的分区。 Kettle并没有针对数据库分区有什么功能。 ETL工具的功能之四：设计灵活性一个ETL工具应该留给开发人员足够的自由度来使用，而不能通过一种固定的方式来限制用户的创造力和设计的需求。ETL工具可以分为基于过程的和基于映射的。 基于映射的功能只在源数据和目的数据之间提供了一组固定的步骤，严重限制了设计工作的自由度。基于映射的工具一般易于使用，可快速上手，但是对于更复杂的任务，基于过程的工具才是组好的选择。 使用Kettle这样基于过程的工具，根据实际的数据和也许需求，可以创建自定义的步骤和转换。 ETL工具的功能之五：复用性设计完的ETL转换应该可以被复用，这是非常重要的。复制和粘贴已经存在的转换步骤是最常见的一种复用，但这不是真正意义上的复用。 taskctl里有一个映射（子转换）步骤，可以完成转换的复用，该步骤可以将一个转换作为其他转换的子转换。另外转换还可以在多个作业里多次使用，同样作业也可以为其他作业的子作业。 ETL工具的功能之六：扩展性大家都知道，几乎所有的ETL工具都提供了脚本，以编程的方式来解决工具本身不能解决的问题。另外，还有少数几款ETL工具可以通过API或其他方式为工具增加组件。使用脚本语言写函数，函数可以被其他转换或脚本调用。 Kettle提供了上述的所有功能。Java脚本步骤可以用来开发Java脚本，把这个脚本保存为一个转换，再通过映射（子转换）步骤，又可以变为一个标准的可以复用的函数。实际上，并不限于脚本，每个转换都可以通过这种映射（子转换）方式来复用，如同创建了一个组件。Kettle在设计上就是可扩展的，它提供了一个插件平台。这种插件架构允许第三方为Kettle平台开发插件。 Kettle里的所有插件，即使是默认提供的组件，实际上也都是插件。内置的第三方插件和Pentaho插件的唯一区别就是技术支持。假设你买了一个第三方插件（例如一个SugarCRM的连接），技术支持由第三方提供，而不是由Pentaho提供。 ETL工具的功能之七：数据转换ETL项目很大一部分工作都是在做数据转换。在输入和输出之间，数据要经过校验、连接、分隔、合并、转置、排序、合并、克隆、排重、过滤、删除、替换或者其他操作。 在不同机构、项目和解决方案里，数据转换的需求都大不相同，所以很难说清一个ETL工具最少应该提供哪些转换功能。 但是呢，常用的ETL工具（包括taskctl）都提供了下面一些最基本的整合功能： 缓慢变更维度查询值行列转换条件分隔排序、合并、连接聚集ETL工具的功能之八：测试和调试测试通常分为黑盒测试（也叫功能测试）和白盒测试（结构测试）。 黑盒测试，ETL转换就被认为是一个黑盒子，测试者并不了解黑盒子的功能，只知道输入和期望的输出。 白盒测试，要求测试者知道转换内部的工作机制并依此设计测试用例来检查特定的转换是否有特定的结果。 调试实际是白盒测试中的一部分，通过高度可以让开发者或测试者一步一步地运行一个转换，并找出问题的所在。 ETL工具的功能之九：血统分析和影响分析任何ETL工具都应该有一个重要的功能：读取转换的元数据，它是提取由不同转换构成的数据流的信息。 血统分析和影响分析是基于元数据的两个相关的特性。 血统是一种回溯性的机制，它可以查看到数据的来源。 影响分析是基于元数据的另一种分析方法，可以分析源数据对随后的转换以及目标表的影响。 ETL工具的功能之十：日志和审计数据仓库的目的就是要提供一个准确的信息源，因此数据仓库里的数据应该是可靠的、可信任的。为了保证这阵可靠性，同时保证可以记录下所有的数据转换操作，ETL工具应该提供日志和审计功能。 日志可以记录下在转换过程中执行了哪些步骤，包括每个步骤开始和结束时间戳。 审计可以追踪到对数据做的所有操作，包括读行数、转换行数、写行数。 对啦，我们的公众号“敏捷调度taskctl”(ID:gh_79ababc7910b)长期更新互联网最新资讯、行业内职场趣闻、以及有趣且实用性较高的编程插件和开发框架知识分享之类的， 如果你开心的话可以关注一下下呢！期待(ー)

背景某项目Oracle 11g RAC其中一个节点vip服务offline，集群从双节点变为单节点 排查crsctl命令查看集群状态$ su - grid$ crsctl stat res -t--------------------------------------------------------------------------------NAME TARGET STATE SERVER STATE_DETAILS --------------------------------------------------------------------------------Local Resources--------------------------------------------------------------------------------ora.ARCH.dg ONLINE ONLINE dbprd1 ONLINE ONLINE dbprd2 ora.CRS.dg ONLINE ONLINE dbprd1 ONLINE ONLINE dbprd2 ora.DATA.dg ONLINE ONLINE dbprd1 ONLINE ONLINE dbprd2 ora.LISTENER.lsnr ONLINE OFFLINE dbprd1 ONLINE ONLINE dbprd2 ora.asm ONLINE ONLINE dbprd1 Started ONLINE ONLINE dbprd2 Started ora.gsd OFFLINE OFFLINE dbprd1 OFFLINE OFFLINE dbprd2 ora.net1.network ONLINE ONLINE dbprd1 ONLINE ONLINE dbprd2 ora.ons ONLINE ONLINE dbprd1 ONLINE ONLINE dbprd2 --------------------------------------------------------------------------------Cluster Resources--------------------------------------------------------------------------------ora.LISTENER_SCAN1.lsnr 1 ONLINE ONLINE dbprd2 ora.asdfprdb.db 1 ONLINE ONLINE dbprd1 Open 2 ONLINE ONLINE dbprd2 Open ora.cvu 1 ONLINE ONLINE dbprd2 ora.dbprd1.vip 1 ONLINE OFFLINE ora.dbprd2.vip 1 ONLINE ONLINE dbprd2 ora.oc4j 1 ONLINE ONLINE dbprd1 ora.scan1.vip 1 ONLINE ONLINE dbprd2 可以看到，ora.dbprd1.vip1状态为OFFLINE，并且ora.LISTENER.lsnr也OFFLINE，监听应该是受vip影响，可以不用去管 ...

什么是调度系统调度系统，更确切地说，作业调度系统（Job Scheduler）或者说工作流调度系统（workflow Scheduler）是任何一个稍微有点规模，不是简单玩玩的大数据开发平台都必不可少的重要组成部分。 除了Crontab，Quartz这类偏单机的定时调度程序／库。开源的分布式作业调度系统也有很多，比较知名的比如：oozie，azkaban，chronos，zeus等等，此外，还有包括阿里的TBSchedule，SchedulerX，腾讯的Lhotse以及我司历尽十年磨砺的TASKCTL 作业系统的两大种类 现在市面上的调度系统根据功能性可以分为两类定时类作业调度系统&DAG工作流类作业调度系统这两类系统的架构和功能实现通常存在很大的差异，下面就来跟大家普及一下这两种作业系统的不同之处； 定时类作业系统定时类系统的方向，重点定位于大量并发的任务分片执行场景； 在实际应用场景中，通常平时维护工作需要定时执行的业务逻辑相对离散无序，仅仅存在一定的简单关联。 例如： 需要定时批量清理一批机器的磁盘空间，需要定时生成一批商品清单，需要定时批量对一批数据建索引，需要定时对一批用户发送推送通知等等。核心目标基本两点： 1.作业分片逻辑支持：将一个大的任务拆分成多个小任务分配到不同的服务器上执行， 难点在于要做到不漏，不重，保证负载平衡，节点崩溃时自动进行任务迁移等 2.高可用精确定时触发：由于平时经常涉及到实际业务流程的及时性和准确性，所以通常需要保证任务触发的强实时和可靠性 所以"负载均衡，弹性扩容"，“状态同步”和“失效转移”通常是这类调度系统在架构设计时重点考虑的特性 DAG工作流类作业调度系统主要定位于有序作业的调度依赖关系的正确处理，分片执行的逻辑通常不是系统关注的粒度，如果某些作业真的关注分片逻辑，通常交给后端集群（比如MR任务自带分片能力）或者具体类型的任务执行后端去实现。 DAG工作流类调度系统所服务的通常是作业繁多，作业之间的流程依赖比较复杂的场景； 如：大数据开发平台的离线数仓报表处理业务，从数据采集，清洗，到各个层级的报表的汇总运算，到最后数据导出到外部业务系统，一个完整的业务流程，可能涉及到成百上千个相互交叉依赖关联的作业。 所以DAG工作流类调度系统关注的重点，通常会包括： 足够丰富灵活的依赖触发机制（如：时间触发任务，依赖触发任务，混合触发任务）作业的计划，变更和执行流水的管理和同步任务的优先级管理，业务隔离，权限管理等各种特殊流程的处理（如：暂停任务，重刷历史数据，人工标注失败／成功，临时任务和周期任务的协同等）完备的监控报警通知机制小结：这两类系统的定位目标，并不是绝对冲突矛盾的，并且从目前定时类调度系统的发展来看，也需要处理一些复杂的作业间强依赖关系了，比如 "微批(少量DAG批量作业处理)" 概念的提出。只不过，要同时圆满的支持这两大类需求，从实现的角度来说是很困难的，因为侧重点的不同，在架构上多少会对某些方面做些取舍，当前这两类系统都没有能够做到完美的两者兼顾。 为什么需要调度系统我们都知道大数据的计算、分析和处理，一般由多个任务单元组成（Hive、Sparksql、Spark、Shell等），每个任务单元完成特定的数据处理逻辑。 多个任务单元之间往往有着强依赖关系，上游任务执行并成功，下游任务才可以执行。比如上游任务结束后拿到 A 结果，下游任务需结合 A 结果才能产出 B 结果，因此下游任务的开始一定是在上游任务成功运行拿到结果之后才可以开始。 而为了保证数据处理结果的准确性，就必须要求这些任务按照上下游依赖关系有序、高效的执行。一个较为基础的处理方式是，预估出每个任务处理所需时间，根据先后顺序，计算出每个任务的执行的起止时间，通过定时跑任务的方式，让整个系统保持稳定的运行。 一个完整的数据分析任务最少执行一次，在数据量较少，依赖关系较为简单的低频数据处理过程中，这种调度方式完全可以满足需求。 然而在企业级场景中，更多的是需要每天执行，如果任务数量较多，在任务启动的时间计算上就将耗费大量时间，另外如果出现上游任务执行时长超出原定预计时间或者运行异常的问题，上述的处理方式将完全无法应对，也会对人力物力造成重复损耗，因此，对于企业数据开发过程来说，一个完整且高效的工作流调度系统将起到至关重要的作用。 写在最后TASKCTL目前是暂时唯一提出 "无序定时和有序DAG作业流" 完整概念的调度产品。既可以在定时中处理 "微批" 的控制，也能够在DAG作业流中处理 "定时" 的控制。 例如： 在大数据分布式（分片）计算中，对数据进行实时ETL跑批处理，在ETL作业跑批中，对某个作业或一段分支进行时间窗口内循环定时处理了解产品信息可以参读： [深入浅出的etl作业调度工具TASKCTL](https://link.zhihu.com/?targe...[etl批量作业集群统一调度平台搭建](https://link.zhihu.com/?targe...随着大数据应用需求的不断膨胀，数据处理的复杂度和实时性要求越来越高。TASKCTL作为国内自主研发的专业调度产品，为企业进入大数据2.0时代做好提前布局。 对啦，我们的公众号“敏捷调度taskctl”(ID:gh_79ababc7910b)长期更新互联网最新资讯、行业内职场趣闻、以及有趣且实用性较高的编程插件和开发框架知识分享之类的， 如果你开心的话可以关注一下下呢！期待(ー)

文章背景日常的工作中，会收到一堆CPU使用率过高的告警邮件，遇到某台服务的CPU被占满了，这时候我们就要去查看是什么进程将服务器的CPU资源占用满了。通常我们会通过top或者htop来快速的查看占据CPU最高的那个进程，如下图： 这里是通过一个普通的服务器做演示使用，如图所示当前服务器占用CPU最高的是一个叫做kube-apiserver命令运行的一个进程，该进程的PID为25633,当然你可能遇到一个服务器上运行有多个服务，想快速知道占用率最高的那几个进程的话，你可以使用以下命令: ps aux|head -1;ps -aux | sort -k3nr | head -n 10 //查看前10个最占用CPU的进程ps aux|head -1;ps -aux | sort -k4nr | head -n 10 //查看前10个最占用内存的进程但是通过以上的方法获取到服务器占用资源的进程之后，还是不知道CPU使用究竟耗时在哪里,不清楚瓶颈在哪里，此时就可以通过Linux系统的性能分析工具perf分析，分析其返回的正在消耗CPU的函数以及调用栈。然后可以通过解析perf采集的数据，渲染到火焰图????，就清楚的知道究竟占用系统CPU资源的罪魁祸首了。 在制作火焰图之前，需要先来说说这个Linux性能分析工具perf,该工具是一个相对简单易上手的性能分析工具，是Performance单词的缩写，通过其perf的命令选项完成系统事件的采集到解析，我们来简单的认识一下： linux上的性能分析工具Perf安装perf我目前的服务器发行版是Ubuntu 16.04.6 LTS因此需要先安装perf才能使用，该工具由linux-tools-common提供，但是它需要安装后面的依赖。 #安装root@master:~# apt install linux-tools-common linux-tools-4.4.0-142-generic linux-cloud-tools-4.4.0-142-generic -yroot@master:~# perf -v #显示perf的版本perf version 4.4.167在安装完成时候，我们就可以对上图CPU使用率最高的进程ID为25633的进程进行采样分析。 首选我们采集一下该进程的调用栈信息: root@master:~# sudo perf record -F 99 -p 25633 -g -- sleep 30[ perf record: Woken up 1 times to write data ][ perf record: Captured and wrote 0.039 MB perf.data (120 samples) ]这个命令会产生一个大的数据文件，取决与你采集的进程与CPU的配置，如果一台服务器有16个 CPU，每秒抽样99次，持续30秒，就得到 47,520 个调用栈，长达几十万甚至上百万行。上面的命令中，perf record表示记录，-F 99表示每秒99次，-p 25633是进程号，即对哪个进程进行分析，-g表示记录调用栈，sleep 30则是持续30秒，参数信息可以视情况调整。生成的数据采集文件在当前目录下，名称为perf.data。 ...

ITIL 4 是 IT 团队新范式转移的开始，指导团队打造一个业务和客户价值的整体参考框架，根据团队需求以及工作方式，鼓励采用更具适应性的方法。ITIL 4 指导原则鼓励协作、简单和反馈。 在指南中（若感兴趣关注【Atlassian速递】公众号可下载全文），Atlassian 和 AXELOS（ITIL Foundation 发起方）携手合作，帮助您快速开启 ITIL 4 敏捷之旅。根据 ITIL 4 的原则，您将学习如何通过绩效、文化和实践建立高效服务团队。Atlassian 发现，这些实践领域对改变 IT 团队的工作方式具有最大的影响。在此过程中，还将学习到有关将敏捷和 DevOps 最佳实践引入 ITSM 的建议。 AtlassianITSM 解决方案 Atlassian 为技术人员提供最关键的协作工作流程——敏捷项目规划、事件管理和响应以及服务管理和支持，帮助现代 IT 组织规划、构建、交付并确保全时服务。我们的产品遍布所有行业，服务各种类型和规模的119,000多名客户。 在开放环境下，所有团队都有潜力做出令人惊叹的成就。“开放式工作”是我们价值观的核心，融入到我们产品的DNA中，我们通过实践体现出开放式工作的内涵。根据我们与高绩效团队合作的经验，结合自己组织中实施开放式工作方式的研究和发现，我们制作了 Atlassian Team Playbook（团队赋能手册）。手册提供了跟踪团队健康状况的详细步骤，以及颠覆的新工作方式。 我们的 ITSM 实施方法具有开箱即用的基本功能，集成各种一流应用程序生态系统；我们的解决方案抛弃复杂、僵化的传统工作流工具，专注于易用性、协作和知识共享，有助于 IT 团队提高效率，保持灵活性并专注于提供价值。 绩效、文化和实践的整体方法 1. 围绕正确的绩效战略 随着 IT 团队的成长，面临着越来越多的工作——请求、缺陷、事件等等，陷入计划外工作的被动循环。要从成本中心转变为价值中心，需要考虑绩效战略。高绩效团队可以降低工作量，加快工作流程，从而专注于更重要的工作。 高绩效战略可以使组织在整个业务周期、行业震荡期间以及领导层发生变化时，始终超越竞争对手。我们应该关注整个组织需要采取的行动，推动创造价值。ITIL®Foundation：ITIL 4，5.1.12，战略管理 ITIL 4 引入了服务价值链的概念，表示任何活动——每个人从单个开发者到整个企业——都可以为客户创建有价值的产品和服务。 ITIL®Foundation：ITIL 4 ITIL服务价值链 2. 借助文化释放团队全部潜力 改变组织文化的任务很艰巨，也不是一朝一夕之事。但是，每一次微小的进步，都会成为改变团队工作方式的力量。使用 ITIL 4 指导原则作为起点，定义自己的核心价值。事实上，ITIL 4 指导原则与敏捷宣言之间的有很多相似之处。因此，通过采用“专注于价值”、“协作和推动可见性”、“整体思考和工作方式”等原则，您已经向建立更敏捷的文化迈进了一步！ 3. 采用灵活实践改变行为 许多 IT 团队以过度规范的方式来解释之前版本的 ITIL，给整个 IT 组织带来沉重而繁琐的负担。过度规范的解释产生了大量复杂的软件模块和孤立的功能团队，每个流程都有一个模块和团队，比如事件管理、变更管理、问题管理等。认识到这一点后，ITIL 4 从分步流程转变为整合“文化、业务目标和利益相关者”的“实践”，共有34种实践，大致可分为普通管理实践、服务管理实践和技术管理实践。 基于 Atlassian 构建软件和与数千个高效团队合作的经验，我们发现绩效最佳的 IT 团队往往会使用以下实践： 利用回顾会议持续改进敏捷项目管理，加快项目交付知识管理，增强团队文化以客户为导向的服务台和请求管理适应性事件管理自动化和协作帮助简化变更控制持续交付的部署管理集成软件开发和运营团队管理实践 ...

艾媒咨询数据显示，2019年，中国直播电商行业的总规模达到4338亿元，预计到2020年规模将翻一番。随着互联网技术的发展，购物场景变革，消费者购物模式也产生了巨大的变化，以直播为代表的KOL带货模式给消费者带来更直观、生动的购物体验，转化率高，营销效果好，逐渐成为电商平台、内容平台的新增长动力。 看此拥有顶级流量大咖，实际更缺流量全民直播的浪潮下，不乏有各界明显大咖跨界直播，3月19日，罗永浩发文表示，决定做电商直播。 4月1日，罗永浩直播首秀的成绩可以说是非常漂亮，首场直播累计观看量接近5000万，在线人数峰值为290万，销售额1.68亿元。 但是，直播过程中也有网友发现了一个不可理解的事情： 本场音浪：827.3万 领先下一名音浪:1396.0万 这是抖音的Bug、数据造假还是网友理解的偏差？一时间网上也是出现了很多质疑声。 随后，老罗在接下来的几场直播中，又遭遇了流量不断下滑以及频发翻车事故的尴尬。第二场直播的累计观看量下降到了1140.7万，在线人数峰值也剩下89.2万。尽管下滑在预期之内，但是足以引发外界对其带货直播能否成功的质疑。尤其是“五一黄金周”的第五场直播，累计观看量更是下滑至了850万，销售额仅剩下2750万元。最近，618期间更是被消费者投诉，商品质量、价格虚高等问题。 “翻车”只是直播中的小插曲，其背后本质是流量和销售额的下滑。直播不是“万能药”，在大家争相模仿直播的潮流中，首先，一个现实的问题就是流量问题，并不是每个企业都适合直播，且是对其运营、营销能力是最大的一个考验。 直播黑灰产:流量变现过程中的“异形”6月8日，前淘宝直播负责人赵圆圆在微博上发布了一则动态，直接diss当前直播电商行业粉饰带货数据、直播数量的现象。不过，目前该微博已被删除。一石激起千层浪，赵圆圆微博带出的直播电商行业数据造假、直播数量问题，引起了广泛关注和讨论。 6月29日，中消协发布的“618”消费维权舆情分析报告中，在直播带货的“槽点”的五点之一中也特别说明直播刷粉丝数据、销售量刷单造假“杀雏”等。 综合来看，直播行业一片红海的情形下，也养肥了一大票直播背后的黑色产业链。顶象专家研究分析直播行业遭遇到风险攻击主要有以下四种： 刷粉刷量：短时间内吸引一定数量的粉丝也是有难度的，没有粉丝基数，又很难获得平台的推荐。大量的直播主在进行刷粉、刷赞、刷评论甚至刷单。 推广作弊：直播行业主要是信息流模式，需要推广的用户可以选在信息流中投放广告推广。黑灰产通过大量养号，以低于平台官方价格承接推广业务后，在大量账号资源中批量发送推广广告，以巨量账号为基础，达到官方信息流的推广效果。 非法传播：很多直播主播通过涉黄直播、淫秽视频、黄色小说、赌博游戏等内容来吸引用户，通过广告、用户充值消费、诱导用户赌博等手段来获取收益。 虚假账号：制作一些假冒的明星或知名人物的账号，利用知名度和影响力吸引粉丝，向粉丝兜售商品、借钱、充话费、推荐产品，并把积累的粉丝吸引到其他工具上，再进行深入的牟利或诈骗。 监管与技术合力防控直播刷单造假中国广告协会制定的《网络直播营销行为规范》于今日起正式实施。规范支出，网络直播营销主体不得利用刷单、炒信等流量造假方式虚构或篡改交易数据和用户评价；不得进行虚假或者引人误解的商业宣传，欺骗、误导消费者。在网络直播营销中发布商业广告的，应当严格遵守《中华人民共和国广告法》的各项规定。 在技术方面，顶象有专业的直播反欺诈解决方案，能够有效防范刷粉、刷赞、刷评论等风险，降低因欺诈产生的风险及损失，助力直播行业健康发展。 此外，由中国商业联合会媒体购物专业委员会牵头起草制定的《视频直播购物运营和服务基本规范》和《网络购物诚信服务体系评价指南》全国性社团标准预计将于今年7月份出台实施，这是首部全国性直播电商标准，也意味着“直播带货”将进入“监管时代”。直播平台更需要真诚正视消费者追求品质的新需求、新动向，切实同步提升行业综合服务能力与服务水平，为供需两侧共同助推经济加速恢复循环的生动实践助力添彩。

WGCLOUD，server端基于springboot开发，agent端使用go编写。支持高并发高性能，核心模块包括：服务器集群监控，ES集群状态监控，CPU监控，内存监控，数据监控，docker监控，网络流量监控，服务心跳检测，应用进程管理，磁盘IO监控，系统负载监控，监控告警信息推送。  此次更新，是针对已安装v3.2的同学，如何替换文件： **1.bug描述，v3.2的agent运行一段时间后会休眠，不再上报数据，此bug只在v3.2里存在 2.如何修复，很简单，只要重新下载v3.2安装包，然后替换/server/wgcloud-daemon-release文件即可，其他都不需要改动。如果是win系统，替换/server/wgcloud-daemon-release.exe文件。最后重新启动server 3.新版本刚发布，难免会出现瑕疵，感谢支持** 码云源码下载：https://gitee.com/wanghouhou/wgcloud GITHUB源码下载：https://github.com/tianshiyeben/wgcloud 安装包下载：http://www.wgstart.com

看具体版本了，我说一种通用的升级办法，比较粗暴哈。 这个版本比较笨，基本上就是重新安装，按照官网的安装说明做就行了，此时官网最新版本是v3.2，以升级到3.2为例说明。 网站：www.wgstart.com 1.替换数据库，导入wgcloud.sql2.替换server/wgcloud-server-release.jar3.替换server/start.sh4.替换server/stop.sh5.替换server/wgcloud-daemon-release，这是3.2新加的守护进程6.替换agent/wgcloud-agent-release 好了，升级完成了

WGCLOUD，server端基于springboot开发，agent端使用go编写。支持高并发高性能，核心模块包括：服务器集群监控，ES集群状态监控，CPU监控，内存监控，数据监控，docker监控，网络流量监控，服务心跳检测，应用进程管理，磁盘IO监控，系统负载监控，监控告警信息推送。  此次v3.2更新： **WGCLOUD-v3.2更新说明，2020-06-27 1.优化，对UI进行整体优化，如字体，按钮，布局，着色等 2.新增，监控概要，主机图表添加显示下线主机数量 3.新增，监控概要，去除监控进程cpu%>90图表模板，新增DOCKER监控数量 4.新增，主机行为分析并进行画像，对监控主机所有信息提取并分析展示 5.新增，agent上报时间间隔由60秒，提升到30秒 6.新增，防篡改保护机制 7.新增，监控主机列表，根据cpu和内存使用率，可以手动排序 8.改造，图表展示，维度由按天调整为按照时间段进行浏览，分别为0-6点，6-12点，12-18点，18-0点，提升图表渲染速度 9.改造，图表展示时间区间，由6天提升到10天 10.改造，定期清空历史数据时间，由凌晨1点改为早上8点 11.bug，对已发现的bug进行修复 12.优化，日志文件配置 13.升级到本版本时候，注意清空下浏览器缓存，消除本地js文件缓存** 码云源码下载：https://gitee.com/wanghouhou/wgcloud GITHUB源码下载：https://github.com/tianshiyeben/wgcloud 安装包下载：http://www.wgstart.com

TCP的Delayed ACK与Nagle算法相互作用造成交易处理延迟，是我们最常见的典型网络故障之一。不久前，某金融机构的运维部门对支付平台程序升级后，就经历了Delayed ACK与Nagle算法相互作用导致交易变慢的问题。我们利用网络故障分析方法一起来看看这个案例。 问题突发这家金融机构的运维人员在完成支付平台的程序升级后，发现新系统的业务处理能力并没有得到明显提高：在支付高峰期，业务交易反而变慢，交易量一直上不去，严重影响用户的在线消费支付体验。反反复复检查网络与应用配置，都没有发现明显异常，最后决定采取捕获数据包来进行分析。   数据包分析运维人员拿到数据包后用分析工具打开，并未发现有丢包重传、服务器响应慢等问题。但是通过TCP时间间隔进行排序，发现了异常现象：间隔中有许多200ms左右的延迟，几乎没有payload数据负载ACK的回应。大家第一时间联想到这些延迟可能是Delayed ACK与Nagle算法相互作用而产生的。   用基于数据流的Dali工具打开数据包，进行时间间隔设置，把超过190ms的触发用红色标记显示。查看数据交互会话流，发现服务端在回复ACK时有连续多个200ms的延迟，这大大降低了数据传输效率，影响业务处理速度。 具体分析每个200ms延迟，发现这些延迟的ACK都没有payload的数据负载，全部在延迟了200ms后确认了之前的同一个数据包。   问题定位通过以上现象可以看出，没有payload数据负载的ACK延迟了200ms左右，这些延迟了的ACK仅仅确认了一个数据包的请求。打开其它的会话发现是同样的现象，最终确定这些延迟就是TCP的Delayed ACK与Nagle算法相互作用导致的。   问题总结Delayed ACKDelayed ACK是TCP 的一种流控手段。如果有响应数据发送时，ACK会随响应数据一起发送给对方；如果没有响应数据，ACK的发送就会有延迟，以等待看是否有响应数据一起发送。 Nagle算法Nagle算法是通过减少网络连接中<MSS的数据包的数量，从而防止网络拥塞的控制手段。任意时刻中最多只能有一个未被确认的小包（尺寸<MSS的数据包）。简单来说，当发送方要发出不满MSS的数据包时，需要前面发出的数据包都得到ACK确认。而接收方因为Delayed ACK的原因延迟了ACK的回应，导致发送方和接收方都在等待，造成了我们所说的ACK延迟。   Delayed ACK+Nagle算法双方不会无限制等待下去，最多不超过500ms，一般情况下系统内核启动的定时器默认200ms的延迟。从0到200循环计时，每隔200ms检查是否有ACK需要发送，因此ACK延迟可能是200ms内任意一个数值。   解决问题Nagle算法只适用于特定的场景。有一种说法认为Nagle算法引入了不必要的延迟，这种说法目前来看适用于多数场景，譬如本案例。该机构在支付平台升级后，Nagle算法默认开启，导致ACK延迟进而影响业务。关掉Nagle算法后，问题得以解决。   自动化服务路径监控解决方案 解决此类问题时，我们需要了解TCP的各种拥塞控制和TCP/IP相关的原理知识，排查分析的过程相对比较复杂。当然也可以通过服务路径监控的方式，进行自动化的持续监控，在出现问题时做到自动化分析、告警，提升运维效率，保障业务稳定。 天旦网络性能管理NPM产品将复杂的网络性能管理化繁为简。NPM利用网络数据包、IPFIX流数据，能够建立覆盖数据中心重要链路、关键设备、核心服务路径的监控视图。将复杂的网络分析技术注入产品的核心技术中，将数以月计的服务路径梳理缩短为周。同时，基于成熟的数据采集与处理技术，能够全量采集网络数据、实时刷新关键网络监控指标、精准告警，并对关键业务的网络行为进行监控、审计和回溯分析，提升业务系统的安全保障能力。————————————————版权声明：本文为CSDN博主「天旦Netis」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/Netis20...

taskctl是什么批量调度自动化技术是大数据时代数据整合后台不可缺少的重要技术。数据是黄金，数据是整个社会乃各企业团体的重要资产，管好数据、用好数据是整个社会的重要命题。想要用好数据，首先就应该管好数据。而批量调度自动化技术，正是管好数据的重要保证。在众多大大小小数据仓库、数据集市以及各种各样的数据池子中，是批量调度自动化技术让大量数据的进出、存放、清洗、过滤、粗加工、细加工等各种各样的工作有序、高效的展开。没有批量调度自动化的数据管理、数据整合等ETL工作，就像一家大公司没有领导，所有工作必将变得紊乱、低效、失控。 没错，批量调度自动化技术对数据整合、对各种各样的ETL，就像领导对公司的意义。同时，批量调度自动化技术又像优秀的职业经理人，没有行业的限制，它是一种与业务无关的纯技术体系。因此，将该技术独立化、系统化、专业化、工具化、产品化，必将给整个ETL技术领域、数据整合领域带来很大的帮助，让整个数据整合技术世界变得更美好。 TASKCTL就是这样一款批量调度自动化技术专业产品。该产品概念新颖，体系完整、功能全面、使用简单、操作流畅，超前的设计使产品在业界独树一帜，它不仅有完整的调度核心、灵活的扩展，同时具备完整的应用体系。该产品特别在流程设计，流程图展示方面与业界同类产品方案相比，不仅取得突破性的进展，而且在图形直观性、操作简便性、灵活性方面有质的飞跃。 产品结构 TASKCTL自动化技术标准产品采用典型的C/S模式，应用层为客户端，控制层为服务端。同时，服务端完成对目标层的调度控制。 应用层 应用层从功能的角度，主要分admin、designer和monitor。从应用渠道的角度，又分桌面客户端渠道与后台字符界面客户端渠道。同时，为了进一步方便用户，系统服务端还提供了丰富的控制操作行命令。 控制层 控制层是多级金字塔架构，顶层为服务控制节点，完成各种调度服务控制以及为客户端提供各种操作应用服务。而代理层完成与目标服务器（ETL等）的控制交互。另，代理层通过主从代理级联方式，可实现对集群部署的服务器进行调度控制，实现负载均衡等。 目标层 目标层，是整个产品所控制的目标，比如我们的ETL服务器，作业工作站等。 核心组件逻辑架构 产品核心是在自主创新核心技术：无数据库存储访问、全事件组件间通信触发（消息队列）、动态数据全内存访问的基础上构建的。 在整个逻辑架构中，每一个组件对应一个系统进程，整个核心功能就是由不同功能的进程有序协同完成。 功能体系 技术咨询:添加微信—"Kitleer"备注"咨询" 十大特征功能十万级作业规模调度支持 TASKCTL从2.0开始，就定位为企业级调度基础软件，能实现10万级任务调度控制，能满足各大企业的调度规模需求。 支持各种技术平台的集成，能实现各种作业类型的调度 TASKCTL是一个开放的调度平台，为了适应诸如Datastage、Informatic、kettle、一体机、大数据、存储过程、java以及各种脚本任务程序的支持与扩展，同时保证不同任务类型的应用统一，TASKCTL对作业的控制采用插件驱动机制，从而实现不同技术平台、不同作业类型调度控制。 多级高可用（HA）、分布式、负载均衡企业级特征 为了保证系统的高可用性、高扩展性，整个产品核心设计采用层级架构。通过"Server(调度控制中心)" + "Agent(代理)"协调工作，完成各种复杂的调度控制，同时，通过Server主备，Server和Agent分布式集群部署，实现高可用性与负载均衡的企业级系统特性。 丰富的应用渠道、完整的应用体系 TASKCTL不仅将系统应用功能按应用类型通过Admin、Designer、Monitor三个软件来组织与应用，同时又按不同应用渠道分C/S模式桌面客户端、C/S模式字符界面客户端以及B/S模式监控应用端。它们分别构成完整的应用系统，用户可以根据自己的操作习惯与具体应用环境，选择合适的客户端渠道进行应用操作。 灵活用户权限管理 为了实现用户对各个作业流程资源的操作控制，TASKCTL采用操作系统的用户管理机制，TASKCTL将设计流程对象化、文件化，每个流程可以对拥有者、同组、其它用户分别授予读、写、操作权限，这种机制可以让用户对不同项目的的不同流程灵活授予读写操作权限。 流程作业的多级组织架构 流程作业信息是调度的核心信息，为了有效管理与控制这些信息，TASKCTL通过主题应用、流程（子流程）、模块等多级体系来组织作业信息，使整个平台的作业信息结构更清晰、更易管理、更易控制。 强大的核心调度功能 ①灵活的流程驱动 一个作业流程的开始，可以通过文件到达触发、自定义周期定时触发（n分钟、n小时、n天等）以及自定义事件触发等。 ②完整的调度控制策略 关系策略：可以实现作业、作业流之间的并行、互斥以及任意依赖控制。特别是依赖控制，系统通过串行、单点依赖、事件依赖以及自定义条件等机制，可以实现作业流内、不同作业流、不同ETL作业服务器以及不同业务日期、不同批次间任意作业的依赖控制。 排程计划策略：实现任意自然日历、逻辑日期排程计划；一个流程内可实现自然日历与多个逻辑日期的混合排程计划。 容错策略：可以实现作业错误后自动重跑，并可指定重跑次数，还可以实现错误重试次数满后，自动决定任务是否通过或失败。 强大的自定义策略：一个任务是否运行、忽略以及等待，用户可以通过自定义条件来确定。一方面，可以采用系统提供的内置函数用于条件判断；还可以通过自定义脚本程序来实现条件判断。 灵活的参数传递：用户可以通过定义全局变量、流程私有变量来实现定义各种信息的宏替换、作业参数传递、流程间变量信息传递等。另外，TASKCTL还可实现一个任务的返回值当作另外一个任务的入口参数来传递。 全方位实时监控作业运行 为了用户实时了解作业的运行状况，TASKCTL整体采用实时刷新、图形、多角度多口径统计以及短信等方式对整个平台作业进行全方位监控，以便用户及时掌握哪些作业正在运行、错误原因、失败、警告等信息 灵活的人工干预维护 人工干预是自动调度系统必不可少的功能。用户可以通过人工操作实现流程的暂停、重置、断点设置与作业的重跑、强制成功以及忽略通过；用户可以通过流程自由模式启动来实现任意作业以及任意作业分支的人工运行等。 专业的图形用户界面 TASKCTL的图形用户界面能够完成上述的所有功能。它将众多功能集成于一个直观的图形界面中，使得用户不用熟悉各种命令、作业定义语言等，就可迅速掌握与使用，进一步方便了用户

近日，一则税务部门发给某电商公司的通知，引发电商行业轰动。 通知提示，该企业为京东、天猫用户，从事网上销售，通过大数据分析比对，发现2017-2019年申报的销售收入与电商平台统计的销售收入差异较大，有少计销售收入的风险。根据相关规定，要求企业根据实际情况自查自纠修改申报表，补缴税款及滞纳金。 通知中提到“申报的销售收入与电商平台统计的销售收入差异较大”，即是对申报给税务部门的销售数据与电商平台统计到的销售收入不符，出现该原因的情况有两个： 第一、网店虚构交易，影响了电商平台统计，也就是俗话说的“刷单”。 第二、网店弄虚作假，隐瞒真实交易，也就是俗话说的“偷税漏税”。 针对电子商务经营者偷税漏税的管理和处罚，《中华人民共和国电子商务法》第十一条、第十四条和第二十八条，《中华人民共和国税收征收管理法》第六十三条等有详细规定。 下面来着重分析电商刷单这一“潜规则”。 刷单的两种形式：机刷与人工刷 电商刷单就是店家付款请人假扮顾客，用以假乱真的购物方式提高网店的排名和销量获取销量及好评吸引顾客，帮指定的网店卖家购买商品提高销量和信用度，并填写虚假好评的行为。通过这种方式，网店可以获得较好的搜索排名，比如，在平台搜索时“按销量”搜索，该店铺因为销量大（即便是虚假的）会更容易被买家看到。 电商刷单已经形成一条产业链，在虚假交易的各个环节中，涉及程序制作、中介服务商、刷手、快递公司等多个角色，上下游行业分工更明确。 电商刷单一般分为单品刷量、销量刷量、信誉刷量，形式有机器刷单和人工刷单两类。 “机器刷单”就是黑灰产团伙利用程序操控账号，自动浏览指定网店或指定商品，并自动完成下单、付款、好评等操作。其特征也很明显：储备了大量虚假账号，在同一设备存在多个账号，经常同一设备短时期高频切换IP地址，浏览下单等操作行为高度统一，收货地址高度统一等。机器刷单成本相对较低，适合大规模批量刷单。 “人工刷单”是电商通过中介机构或第三方平台发布任务，利用专职或兼职刷客的真实账号进行人工刷单。人工刷单由于是真实账户操作，且在浏览、交易上有明确的要求，收货地址相对分散。不过人工刷单成本较高，不符合黑灰产大规模、低投入、高利润的需求。 如何防范电商刷单 针对电商刷单的行为特征，顶象提供了从客户端到业务端的全链路防控体系，可有效防范刷单行为。 首先，设备指纹、风险核验、无感验证等能够及时发现账号注册和登录的多开、群控、系统刷机等恶意设备、恶意IP等。结合Dinsight实时决策引擎，对注册、登录、领取等操作进行实时识别判定，防范黑灰产恶意批量注册，储备虚假账号。再基于关联网络对数据进行分析，挖掘出刷单团伙关联关系及潜在风险。借助Xintetll智能模型平台，构建专属风控模型，进一步提升整体防控能力，从而有效防范电商刷单行为。 在防范电子商务经营者刷单方面，《中华人民共和国电子商务法》和《中华人民共和国反不正当竞争法》也有明文规定。 《中华人民共和国电子商务法》第十七条电子商务经营者应当全面、真实、准确、及时地披露商品或者服务信息，保障消费者的知情权和选择权。电子商务经营者不得以虚构交易、编造用户评价等方式进行虚假或者引人误解的商业宣传，欺骗、误导消费者。　《中华人民共和国反不正当竞争法》（2019年修正）：第八条　经营者不得对其商品的性能、功能、质量、销售状况、用户评价、曾获荣誉等作虚假或者引人误解的商业宣传，欺骗、误导消费者。经营者不得通过组织虚假交易等方式，帮助其他经营者进行虚假或者引人误解的商业宣传。 2017年6月20日，杭州余杭区法院对全国首例因刷单炒信而获刑的案件一审宣判，认定“90后”被告人李某通过创建平台、组织会员刷单炒信并从中牟利的行为构成非法经营罪，判处其有期徒刑5年6个月。此案是全国首例个人通过创建平台、组织会员刷单炒信并从中牟利而获罪的案件。 一年一度的618网购节已经开启，顶象将帮助广大电商平台有效防范刷单、炒信、薅羊毛等各类风险。现在加入“618电商扶持计划”，更可以免费获得顶象风控套装服务。 立即接入： https://www.dingxiang-inc.com/page/20200618

今天的IT技术，又处在一个新的转折点。全面云化、智能化、以及技术的变革为我们带来机遇的同时也带来了挑战。 如何打造出可信的高质量产品？全面提升软件工程能力和实践，才有可能！ GNSEC 2020 全球新一代软件工程线上峰会专注于全方位的软件工程和技术，致力于定义新一代的软件工程。 GNSEC 定义了新一代的软件工程，旨在聚集软件工程行业的专家、学者、从业者，讲述重要的最新研究成果，并分享最前端的实践经验，同时促进产、学、研领域的专家互相交流与合作。 京东智联云云产品研发部架构师任龙涛受邀参加此次线上峰会，将与大家分享《运维堡垒机-高效安全运维设计与实践落地》 《运维堡垒机-高效安全运维设计与实践落地》 主讲人：任龙涛 京东云与AI事业部云产品研发部架构师，大连理工大学软件学院本科、硕士研究生学历，近7年的自动化运维平台研发经验。曾就职于大唐电信，从事信息安全与自动化运维平台研究与开发工作，负责信息安全通信、监控系统、运维工具等系统设计研发。2018年加入京东智联云，从事自动化运维平台设计与开发，负责运维堡垒机、调度系统等系统的架构和设计，在容器化、云原生、安全等方面有着丰富的实践经验。 内容大纲 企业信息化过程中必然要遇到的问题运维堡垒机发展历程京东智联云运维堡垒机系统设计与架构、技术特点京东智联云运维堡垒机实现落地运维堡垒机未来发展展望和愿景活动时间06月19日（周五）14:40-15:05 点击【阅读】获取报名链接 福利！转发本文，并集齐30个赞进行后台回复 前3名小伙伴将免费获得此次峰会门票哦~ 英特尔智慧云基石，助您快捷上云、高效用云、轻松管云 采用第二代英特尔®至强®可扩展平台的云架构，可以获得性能强劲、简单易用的云化基础设施，降低上云复杂度，可用于构建云化的统一数据平台，为数据处理、分析和AI提供全面加速，还通过融合自动化和智能化管理特性，助力实现云的弹性扩展、稳定可靠和降本增效。

WGCLOUD基于java语言开发，是springboot构建的监控系统，支持高并发高性能，核心模块包括：服务器集群监控，ES集群状态监控，CPU监控，内存监控，数据监控，docker监控，网络流量监控，服务心跳检测，应用进程管理，磁盘IO监控，系统负载监控，监控告警信息推送。  此次更新： 修复docker图表显示不准确问题。修复测试邮件发送错误问题。以上bug，在已安装v3.0基础上，只需要重新下载安装包， 然后只替换/server/wgcloud-server-release.jar即可。码云源码下载：https://gitee.com/wanghouhou/wgcloud GITHUB源码下载：https://github.com/tianshiyeben/wgcloud 安装包下载：http://www.wgstart.com

还在用windows自带的记事本或写字板编辑文本文档？ 还在用window自带的搜索服务查找文件？ 还在手动备份重要数据和资料？ 如果你对以上三个问题中任何一个的回答是“是”的话，我建议你看完下面的内容。 我会简单的介绍三个十分有用的免费软件，保证能提高你的办公室工作效率，为你节约出大量的时间用来刷知乎。 注：前方多图，非wifi读者注意避让。 一、Notepad++ 这是一个免费但强大的文本编辑工具，只要用过一次，你就再也不会想打开windows自带记事本或写字板了。而且整个软件十分小巧，安装包才4M多。 官方下载连链接：Notepad++ v7.5.7 - Current Version，下载最新版的installer，双击，无脑下一步就行。 安装完成后，应该会自动在右键菜单添加一个“edit with notepad++”选项，可以用于打开任何纯文本文档： 打开后的界面是这样子的，支持常见的程序语言格式（包括latex)、代码高亮、自动补全等功能，建议在 设置-首选项-文件关联 中关联自己常用的文件格式： 可以同时打开多个文件，并且ctrl+shift+s批量保存文件，拖拽文件标签可以打开 双视图模式 支持多文件批量查找、计数、替换，并且支持正则表达式： 按住alt键再拉光标，可以进行多行的列编辑（编辑规律的数据超好用有没有）： 二、Everything 这是一个文件搜索软件。比windows资源管理器自带的搜索功能上强大很多，而且搜索速度非常快，除第一次需要初始化之外，不管文件夹多大几乎每次搜索都是秒出结果。 官方下载连链接：Downloads - voidtools 。软件同样很小巧，installer只有1M多，下载双击后，无脑下一步就行。 安装好，运行，建议在 工具-选项-常规 里把“集成到资源管理器右键菜单”勾选并应用。 这样，在任意文件夹里点击右键，会出现搜索Everything选项： 点击后，就能在当前目录及所有子目录下搜索文件，例如输入.txt，就能搜索所有txt格式的文件，多个关键字用空格（逻辑与）或“|”字符（逻辑或）分离： 支持区分大小写、匹配文件路径、正则表达式、按文件类型搜索： 支持高级搜索： 搜索处理大量文本时，配合Notepad++食用味道更佳： 选择上图中的“复制完整路径和文件名”，可以批量输出文件路径，创建文件地址数据库，方便用python等文本处理脚本批量调用。 三、FreeFileSync 自从隔壁实验室同学因为火灾把电脑烧毁导致延期毕业后，我所有的重要数据都是本地一份，同步盘随时同步一份（国内可以用 onedirve 或者 坚果云），移动硬盘每天定时同步一份。 FreeFileSync就是用于本地自动备份和同步文件的软件，大部分功能免费。 官方下载连链接：FreeFileSync 。下载运行安装后，界面如下。看起来稍微有点复杂，但只需要设置一次，保存成批处理程序以后自动执行即可： 首先把你的所有需要备份的重要数据整理到一个文件夹内，把这个文件夹地址输入到上图左边的路径框中。在创建一个存放备份文件的文件夹（建议放在另一个硬盘，通过物理隔离保护数据），地址输入到右边的路径框。 然后点击“比较设置”，选择“文件时间和大小”，也就是根据文件的修改时间和大小，来判断文件是否和备份文件夹中的一致，从而判断是否需要更新备份。 再点击“同步设置”，选择镜像。这样一来，任何对重要数据文件夹的修改都会同步到你的备份文件夹中。 然后点击“另存为批处理程序”，点击另存为，得到一个xxx.ffs_batch文件。 以后，只要双击运行这个xxx.ffs_batch文件，程序就会自动同步并备份你的数据了。是不是很方便很省心？告诉你，还有更省心的。关注公众号Java面试那些事儿，回复关键字面试，获取最新的面试题。使用windows自带的“计划任务”功能，可以定时自动执行xxx.ffs_batch程序，从而完全不用你管自动备份你的重要数据。 ...

ONES Pipeline（持续集成与交付管理）整合 DevOps 工具链，集中可视化 CI/CD 全过程。近期，ONES Pipeline 对代码关联集成能力、流水线管理能力、项目内研发数据管理的能力进行了重大升级。升级内容如下： 1. 代码关联集成能力提升 新增「代码仓管理」功能，支持系统关联代码仓自动配置 Webhook；代码提交可关联至工作项、迭代，研发团队可在 ONES Project 中第一时间了解代码关联结果。 2. 流水线管理能力提升 全面兼容 Jenkins 的流水线，流水线构建过程可视化，帮助研发团队更直观、更清晰地跟进持续集成过程。 3. 项目内研发数据管理能力提升 项目新增「流水线组件」功能，迭代新增「流水线运行」功能，通过流水线关联，将构建、部署与项目、迭代整合到一起，实现持续集成与交付管理，形成研发管理闭环。 使用指南 代码关联 1. 代码关联集成在 Pipeline 配置中心的代码仓管理页面，点击「新建关联代码仓」以关联当前团队所需代码仓。系统支持关联 GitHub 或 GitLab 的代码仓。 2. 配置 Webhook新建关联代码仓后，系统会自动在代码仓中配置 Webhook，从而实现 ONES 监听代码平台上的特定提交事件。 如果 Webhook 失效或被人为删除，可点击「重置 Webhook」按钮，系统将自动重置代码仓中的 Webhook，你也可以前往代码仓手工配置。 3. 代码关联工作项在代码提交时，通过输入包含工作项 ID 的方式即可实现与工作项关联。一次代码提交支持与多个工作项同时绑定，请在多个工作项 ID 之间添加空格作为分隔。 代码关联工作项后，你可以在工作项、迭代的「代码」功能查看关联结果；在迭代概览中，查看代码提交次数、提交行数角度的统计报表。 流水线管理 1. 关联 Jenkins 服务进入 Pipeline 配置中心，点击「关联 Jenkins」可编辑或修改关联的 Jenkins，目前一个团队只能关联一个 Jenkins 服务。 ...

作为一个热爱看丧尸片的女编辑，我曾被多位宅客频道同事吐槽口味很重。 天啦噜，我只是喜欢看丧尸围城这种精彩刺激的情节，哪像有些同事去排队抢过优衣库与KAWS合作T恤，这才是现实版“僵尸大战”好么？ 赛博世界的“另类丧尸临城”也很有意思。一种是喜悦划过嘴角，业务量上涨，尤其如果平台搞了大促，用户一拥而上，这种简称为“人肉版”DDoS。还有一种是正经 DDoS，别想了，就是有人要搞你，比如最常见的游戏业，如果一款游戏爆火，它的安全做得又那么随意，眼红的竞争对手可能要派攻击者来搞一把DDoS。 这类“僵尸大军”会堵在“门口”，不让真正的用户使用业务，或者频繁无效地抢占业务入口，搞瘫系统。可怕的是，发展到现在，黑产已经可以用少量的带宽打出巨量的 DDoS 攻击，轻而易举地把一个系统打趴下。 就像懵懂无知的年代，如果一个男生被欺负，可能会愤愤不平地对方说：放学你别走。然后，找一堆“兄弟”前去助阵。 一般企业平常没有储备对抗上T大流量攻击的能力，但他们想到了一个办法——上公有云，号召五湖四海的“兄弟”，一起抗衡超大流量的攻击。 我们把这种动作称为“云化”。 换了一个环境，安全迎来挑战，很多安全公司提出了自己的解法和产品，甲方爸爸要做的就是捋清楚自己的需求，花钱购买安全产品和服务，像串羊肉一样串好自己买的“武器”，这是一种解法。 另一种解法则是由公有云安全厂商提出，他们的理念是，既然我们提供了最好用的云，我们也要提供最好用的云安全产品和服务，后者的核心是“云原生安全能力”。 知己知彼云的原生安全能力有什么不一样？以占据国内公有云市场大半江山的阿里云为例。 既然强调“原生”，与前一种解法的不同当然是“统一”：统一的身份接入、统一的网络安全连接、统一的主机安全以及统一的整体全局管理。 无论是将军带兵打仗，还是企业安全守卫者与攻击者对阵，最重要的一条兵法就是“知己知彼”。云原生安全能力中的其中三项能力都是为此努力。 第一，了解自己有什么，边界线在哪里，有哪些薄弱点，哪里正在遭受入侵。 云的天然优势是“网络的虚拟化调度能力”，企业可以清晰的看到自己主机东西南北向的流量，统一管理好自身边界安全问题，包括对外的安全边界以及内部资产之间的安全边界，公网资产暴露情况、端口暴露情况，甚至是正遭受攻击的情况一目了然。 第二，如果说第一条是从自身角度出发，我们还需要知道“大局”。 云具备实时的全网威胁情报监测和分析能力，打破单点视线的局限，知道整体环境的“变化”。但这还不够，如果一有风吹草动，士兵就得出动勘察及作出行动，对于现实战争而言，可能还可行，但是对于网络威胁而言，完全行不通，天知道浩如烟海的威胁告警中哪些应该真正值得注意？就算人力可以分析，问题是没有这么多人力可以实时待命，所以从发现威胁到主动防御的自动化响应是一项迫切的要求。 第三，我要知道什么人是我的员工，员工是否正在干权限范围内的事情，但是如果企业内部业务系统太多，怎么办？当企业拥抱云并享用SaaS级服务带来效能的同时，基于云的统一身份管理认证成为关键。 企业安全事件中有接近50%都是员工账户权限问题导致的。基于云的 API 化等原生能力，企业可以对身份权限进行统一的认证和授权，并可以在动态环境中授于不同人不同权限，让任何人在任何时间、任何地点，以正确、安全、便捷的访问正确的资源。 安全的本质是为了保障业务的连续、顺利进行，如果还能提升业务效率，简直就是享受买一送二的增值喜悦。 云原生安全能力的后三项是为“知彼”准备的。 它坚守的第一条准则是，“我知道攻击者一定都是时时存在，并且锲而不舍，所以我要把自己打造得更安全”。将安全下沉到底层硬件与可信环境是一种选择，但是困境依然是：没人没钱，成本高，但是云原生内置的安全芯片就不一样了，公有云厂商将安全芯片的底层硬件能力开放给使用者，并构建可信环境，很简单，不需要用户自己辛苦布人布局，且“众筹”给公有云的成本要低很多。 第二条准则是，“我知道攻击者一定会盯上我最宝贵的数据，我知道它想要这个”。未来随着数据安全、用户隐私数据保护要求越来越高，全链路的数据加密一定是云上企业的最大需求。基于云原生操作系统的加密能力，秘钥由企业自己保管，无论是云服务商、外部攻击者、内部员工没有秘钥都无法看到数据。 第三条准则是，“我知道无论自己怎么预防，攻击者都会来，所以我要比预防还快一步”。在云和互联网模式背景下，业务的频繁调整和上线对业务流程安全提出了更高的要求，从源头上做好安全才能消除隐患。基于云的原生能力，安全可以内置到全流程的设计开发过程中，确保上线即安全。 混合云的需求问题来了，企业上云不是一个一蹴而就的“动作”，而是一个时间跨度比较长的过程。越是大型的企业，历史包袱越重，上云的时间越长。 还有一些企业自己的业务做得好好的，本来没有上云的需要，突然要做一些创新的业务需要上云。 因此，可能出现一个在“公有云”“私有云”“专有云”中排列组合游戏：混合云，也就是说，企业中可能有好几朵云，那么，这与公有云的云原生安全能力所说的“统一”又有什么用，难道能在本地与公有云，或者几朵云中共用一套云安全方案吗？ 有这种解法。 阿里云智能安全总监葛岱斌说，混合云安全方案的形成其实靠用户发展需求或者遭遇的安全事件驱动。 有一家企业用了四朵云，并用专线把四朵云打通，一天，企业发现自己遭遇了蠕虫式病毒，刚开始，他只在阿里云上应用了云安全中心，心想要不也在其他几朵云上部署一下安全中心，看看其他云有没有受到影响，结果发现其他云已经中毒了。 这是第一个需求：能否给四朵云应用同一套安全中心，就像一个有钱业主在四个小区都有房，业主心想：这四套房要是都由同一个物业公司管理，有一样的安保系统就好了。 还有一种需求是，降低运营成本，保证业务的连续性，就像开头提到的“僵尸大军”的故事一样，把本地接口交给公有云，扛住攻击。 但是混合云还有“天然的基因缺陷”：不一样的资源管理、不同的底层架构、不一致的安全工具。 从原生能力落地的化繁为简葛岱斌思考，混合云安全主打的云原生安全能力应该落在四个方面。 采用混合云时，安全的边界变得模糊不清，怎么缩小边界？ 身份成了最小的逻辑边界。 “这时需要一个统一的身份认证，到底有哪些人可以访问应用，如何访问，有哪些应用的权限。以前做法是内外网分属不同系统，我们希望给他一个统一的身份认证体系，不管是外网用户还是内网用户，无论认证源是设在公共云还是在私有云上都可以，只要认证一次就行。”葛岱斌对宅客频道说。 就像现在的有些大学校园没有围墙，但师生进入各类实验室要靠刷卡或刷脸，虚拟环境给了用户一把更强大的“钥匙”：只要认证一次，就被系统记住，更加便利。 除了将身份变成边界，还可以把边界扩大到“无垠”：专有云和私有云不需要有互联网的暴露面，将所有流量入口放在阿里云上，无论是内部员工还是外部用户，访问的都是阿里云的接口，虽然用户和攻击者都不知道流量已经悄悄回到了企业内部的IDC中，暴露面降低，则安全风险降低。 “以前设置一个DMZ区（边界区），所有的流量经过这个DMZ区，但是现在流量全部从阿里云过来，相当于把边界交给了阿里云，阿里云是你的边界，我只要把阿里云的边界做好。”面对潜在的攻击者，葛岱斌祭出“虚晃一招”，企业则从原来“雇了几个保安”转变到将安保工作交给了“安保公司”。 这一招也叫作“统一接口”。 有些用户有自己的机房，后来因为业务需求把一部分业务放到公有云上，还有的用户有几万台分布式的服务器，如果云上有一套安全系统来管理安全，线下服务器的安全怎么管理？几个地方的服务器怎么管理？ 就像前面提到被蠕虫病毒侵蚀的四朵云的用户，服务器的安全其实可以被统一起来，无论线上线下，通通交给云安全中心。还可以把探针部署到其他云平台上做统一的检测，做统一的响应，因为只要所有云的 API 接口也开放了，云安全中心就可以调用 API 做响应。 和想要由同一个物业来管理自己四套房子的房主一样，安全管理也可以统一，不过，有些政企用户的考虑是，大部分资产在线下，只有少部分资产在云上，如果使用统一管理平台，干脆直接将控制台从云上搬到云下也是可选的选项。 “我们想要做的就和整个阿里巴巴的理念一样，让天下没有难做的生意，让天下没有难做的安全运维。”葛岱斌对宅客频道说。 说白了，这一套混合云安全方案的直接目的并不是像安全服务提供商一样做可以挣钱的安全方案，而是让阿里云飘得更远，被云覆盖的用户以更低的成本、更少的专业安全人员、更轻盈的方式获得更大的安全。 天下武功路数纷繁，阿里云安全想做的，是化繁为简，更少地向对手暴露“薄弱面”的同时，打破威胁情报、数据、运维的藩篱，登泰山顶，众山动向一览无遗。 赛博世界如同战场，随时面临威胁，没有人可以做到永远安全，但安全可以更简单。 本文作者：李勤 阅读原文 本文为云栖社区原创内容，未经允许不得转载。

翻译：@AdolphLWQ项目地址用时: 10h本文介绍Uber存储平台团队是如何管理自己的存储基础设施的。他们把基础设施抽象成图模型，以此收集状态，然后根据这些信息执行运维任务、制定决策。易于获取当前系统状态对于规模化构建、维护基础设施至关重要。由于Uber的商业持续扩张，我们的基础设施在规模和复杂性上不断增加，使得我们必要时获取所需信息变得很困难。 为了解决这个问题，我们开发了Grail，一个聚合状态信息并在一个全局视图中展示、横跨多个数据中心和区域的平台。有了Grail，我们可以更容易地开发快速、健壮的运维工具。 继续阅读以了解Grail如何通过图模型，根本性地改变Uber工程部门操作存储的方式，使团队更容易缝合不同源头的数据。 设计简单的管理方式2016年末，为了支撑不断增加的负载，我们把所有数据库主机从旋转式硬盘更新到固态硬盘。有一步很重要，就是依然能够鉴别和追踪使用旧硬件的成千上万数据库。 那时候我们没有容易的方式获取设备的当前状态，并且还要追踪大量脚本和任务。这驱使我们寻找不同的方法来开发大规模运维工具，需求如下： 持续收集整个基础设施的状态。唯一的全局视图。低延迟从所有数据源获取所有数据。关联所有数据源的数据。简单添加和删除数据源。Grail简介不像Metricbeat和osquery等类似信息收集系统，Grail不收集特定领域的信息，它的角色是一个平台，以高可用和响应式的方式聚合、链接和查询来自不同数据源的数据，例如主机、数据库、部署和所有权等信息。它高效隐藏了实现细节。 此外，你可以接近实时的方式，快速获取下面问题的答案： 哪些主机当前空闲空间超过4TB？某个团队的数据库使用多少磁盘空间？哪些数据库运行在旋转磁盘上？如果你的服务和主机很少，这些问题就不重要。你只需要写一个脚本，在需要的时候直接收集信息就行了。但是以Uber的规模，当你有一堆服务和数十万主机时，这种方法就失效了。节点太多响应就会慢，查询完后数据关联会出错，结果也不能反映真实情况了。大规模场景下很难及时收集状态。 一个关键结论是“不存在唯一的真理来源”。数据中心和系统的信息总是分布在多个地方，只有把它们关联起来才能做决策。更复杂的是这些状态一直在变：主机的空闲磁盘空间在变、供应新的存储集群、并行发生的其它事件。整个系统的状态不可能实时获取，只能接近它。 规模化维护Uber的存储平台团队开发维护的存储系统支撑了拍字节的关键任务数据，我们的运维工具有一套标准的自我修复范式，有三个简单步骤：首先我们收集系统状态，然后和正常状态比较，最后处理异常数据。 如前文所述，在大规模场景下，不使用Grail这样的聚合平台是很难收集状态。举个例子，当我们想获取所有运行主机当前状态时，比如trips数据。首先我们要先找出哪些主机包含这个数据。接下来我们要连接到这些主机并收集当前状态。最后转换并展示结果。 有了Grail，我们只需要运行一条查询语句，就可以获得需要的信息： TRAVERSE datastore:trips ( SCAN cluster ( SCAN db ( SCAN host ( FIELD HostInfo ) ) ))结果以json文档的形式返回，与查询结构非常相似，对代码友好。下面的代码片段展示了运行上面查询语句的精简版结果： { "__id": "datastore:trips", "cluster": [{ "__id": "cluster-trips-us1-44", "db": [{ "__id": "cluster-trips-us1-44-db26", "host": [{ "__id": "host:database862-sic1", "HostInfo": { "cpuCount": 24, "puppetRole": "database", "memory": { "freeBytes": 1323212425, "totalBytes": 137438953472 }, "disk": { "freeBytes": 48289601723, "totalBytes": 1598689906787 } } }] }] }]}拼接数据Grail围绕对Uber基础设施的两项观察进行设计。第一，基础设施中节点和节点间的联系可以很自然地建模为图。 ...

原文地址：https://medium.com/faun/10-great-books-for-aspiring-devops-sre-engineers-76536c7c4909 原文作者：Aymen El Amri 翻译君：CODING 戴维奥普斯 以下书籍是推荐给 DevOps 或 SRE 工程师阅读的好书清单，用来学习或增强必要的技能。我们找到了原文清单里英文书籍对应的中文版，希望对大家能有帮助。 CODING 也会持续关注并分享 DevOps 领域最新理念与技术，与 DevOps 工程师一起成长。同时文末有福利放送，别忘了领取！ 1、《DevOps 实践指南》 这本书是本清单中最出名的书籍之一，《DevOps 实践指南》是作者丰富的实践指南和多年学习的成果，也是 DevOps 社区中最具影响力的书籍之一。如果你正在搜寻一些历史案例和商业案例以便进行精心研究，试试这本书吧。它是 DevOps 世界的参考书，我非常喜欢它并强烈推荐给开发人员、运维工程师和 IT 经理阅读。 特别适合以下读者：如果你对 DevOps 领域感兴趣：包括团队组织设计、DevOps 文化和相关技术。 2、《微服务设计》 《微服务设计》是一本阅读体验很不错的书， 它写得深入浅出，易于理解。 其中一部分基础主题：如团队建设、版本控制、日志记录、监控等等，会让你从中找到一个非常好的微服务介绍。作者知识渊博，对微服务有相当丰富的经验，同时这本书对初学者也十分友好。 特别适合以下读者：想要学习构建基于微服务架构的应用程序的朋友。 3、《基础设施即代码》 本书是关于云自动化、基础架构和 DevOps 行业最佳实践的综述。它写得很全面，与同类技术技术书籍对比，你在本书中能够欣赏到对于概念和方法的清晰解释和良好措辞。 特别适合以下读者：如果你对 Netflix、Amazon 和 Etsy 等组织的成功经验感兴趣，并希望加强自己的管理技能。 4、《Effective DevOps（中文版）》 这本书不仅仅是一个技术指南，也是一个文化和管理指南。 DevOps 是关于团队协作和文化挑战的理念，本书更多地关注这些人性化方面。通过描述失败和成功案例，以极好的方式将 DevOps 的技术和文化连接起来。 这本书总结了 DevOps 是什么：“一个强调持续努力打破信息孤岛与监控关系，并修复组织团队内部误解的专业文化运动。” 特别适合以下读者：如果你希望实现和维护团队的 DevOps 文化。 5、《SRE：Google 运维揭秘》 谷歌如何运行生产系统？本书通过良好的结构回答了这个问题。我喜欢这本书是因为读者不需要按照任何特定顺序阅读，每一章都是一个独立的主题。这本书是亚马逊最畅销的书之一，可能也是这份清单中最好的一本。 特别适合以下读者：如果你想了解 SRE 日常工作的理论和实践（从构建到运维大型分布式系统）并探索 Google 管理方式如何用于培训、沟通和会议。 ...

服务心跳机制主要用于确认服务的存活状态，UAVStack的心跳数据还负责上报节点的容器及进程监控数据，支持在前端实时查看应用容器和进程的运行状态，并根据这些数据对容器和进程做出预警。 一、背景在微服务架构中，服务心跳是一个简单但非常重要的机制，用于确认微服务的存活状态。UAVStack中的心跳是一个Http请求，MonitorAgent（以下简称MA）通过定时向HealthManager（以下简称HM）发送一个带有特定报文格式的Http请求完成一次心跳的发送过程。心跳报文含有发送时的时间戳，用于更新HM端的数据状态。 与普通的心跳不同，UAVStack中的心跳还负责上送MA端的应用容器和进程监控数据。每次发送心跳的时候，在MA端会有定时任务去收集MA所在的应用容器心跳的基本信息，及应用容器上的进程数据，随着心跳数据包一起上送。 本文将首先介绍UAVStack的基础心跳机制，之后对应用容器、进程的数据采集做详细说明。 二、基本架构心跳的实现有很多种方式，心跳的发起可以由客户端发起也可以由服务端发起，只需完成确认存活这一基本功能即可。但是在一般的实现中，我们更倾向于客户端主动向服务端进行报告，因为当客户端逐渐增加，单纯通过服务端的轮询会导致服务端的压力，影响性能。 在UAVStack的实现中，我们也采用了这样的方式，通过客户端（MA）主动向服务端（HM）发送心跳信息，告知HM自身的存活情况。 一次心跳由UAV的MA和HM共同完成： MA定时生成心跳数据，携带MA节点的应用容器信息、进程信息以及服务信息，通过Http请求上报给HM；HM负责将接收到的心跳数据存入Redis缓存，并定时扫描心跳数据，确认节点的存活状态。对于随同的应用容器等监控信息，会在Redis进行暂存，后续随着HM的定时任务最终存入OpenTSDB进行落盘。整体的架构如下所示： 三、基础心跳机制 心跳服务主要流程如上图所示，其逻辑有以下几步： 1）MA的定时心跳任务生成一个空心跳数据，将心跳数据交给MA端的容器、进程数据采集任务。 2）MA端的容器、进程数据采集任务负责产生心跳数据的时间戳、采集节点的应用容器、进程监控数据、节点的基本信息、节点的可用服务信息等。经过以上过程之后，心跳数据将包含以下内容： 心跳时间戳：节点发送心跳时的时间戳，方便HM后续比对判定节点的存活状态。应用容器的基本信息：包括节点ID、名称、主机名、IP等。应用容器的简单监控数据：包括CPU负载、内存使用、硬盘使用等。应用容器上的进程信息：包括每个进程的pid、资源占用等。节点的能力信息：包括该节点上启用的Feature功能。节点的服务信息：包括该节点上可提供的服务及其访问接口，用以实现服务发现。可选）子节点的节点信息：如果MA和HM部署在不同的网段，则MA无法通过直接Http的方式推送数据给HM，此时需要MA将数据上送给自己网段内的HM，再由该HM的心跳客户端发送给总的HM。这种情况下，上报的数据中会携带子节点的节点信息。每个节点信息均会包含上述几种数据。最后将心跳数据发送给HM。 3）HM端在接收到心跳数据之后，将其存入自身的Redis缓存。使用上报数据中的服务信息更新Redis中的服务状态，用于服务发现请求。 4）HM端在启动心跳接收服务时，会同时启动心跳检查任务。这个任务会定时扫描Redis中的心跳数据，根据当前系统时间与心跳时间戳的差，判断心跳节点的存活状态，更新节点的状态，并对于过期的节点做删除处理。 四、应用容器、进程数据采集UAV的心跳数据除了完成心跳功能之外，还要上报节点的应用容器及进程的监控数据。 将应用容器与进程数据通过Http方式上报是为了保证应用容器监控数据与应用监控数据的隔离，通过不同方式的上送可以保证在MQ服务不能使用时不影响容器与进程数据的采集。 本节将集中说明这些数据的采集细节。 4.1 应用容器数据采集应用容器的数据分为两部分： 其一是容器的基本信息，即节点的ID，主机名，系统信息和JVM信息等； 另一部分是一些简单的实时监控采集数据，包括CPU的负载、内存占用情况和磁盘占用情况等。这些数据在每次上报心跳数据的时候会分别从以下数据源实时采集： 应用启动后的System.getProperty：这部分数据主要包括操作系统的基本信息，JVM信息等。Java提供的工具类：这部分主要包括网卡信息。通过JMX获取的信息：包括CPU占用、内存占用等。系统本身记录的信息：这部分包括可提供的服务信息、启动的Feature信息、节点ID等。通过执行系统命令得到的信息：包括磁盘占用情况。通过直接读取/proc目录下的文件获取的信息：包括CPU占用、内存占用等。4.2 进程数据采集不同于应用容器数据采集，进程的数据并不是在心跳进程中进行采集的，而是由专门的Feature负责。在Feature中将进程数据采集进一步分解成进程端口流量数据采集以及其他数据采集。这两者均由定时任务完成，互相协作，最终由进程探测的定时任务更新心跳客户端的进程数据。 这种使用多个采集任务分别采集的方式可以针对不同的数据进行不同频度的采集。如对于网络端口流量的采集，就可以以更长的周期进行，以减低数据采集带来的性能损耗。同时，不同的任务也可以使用不同的线程执行，提升执行的效率。 进程数据采集流程大致如下图所示： 进程端口流量探测定时任务每隔一定时间读取本地变量端口列表，获取要采集的端口号。 之后对于Windows环境，采用JPcap获取网卡对象，并在网卡上设置tcp过滤器来统计一段时间内的端口流量。对于Linux环境则是直接通过调用Python脚本打开socket，分析流过的数据包获得。 获得全部端口上的流量数据后，任务会将采集数据交给进程数据采集任务，更新其本地变量，同时设置本次采集的时间戳。 进程探测定时任务由一系列子任务构成，在任务开始的时候，会先准备好一个Map结构的数据容器，用于存放采集到的进程信息，每个进程由pid区分，作为Map的key。 任务会先扫描所有的进程，获取pid和进程的端口。扫描到的进程会经过一个过滤器排除不需要采集数据的进程，之后正式采集每个进程上的数据。 对于每一个进程，会通过运行系统命令采集连接数、CPU、内存占用，磁盘读写数据以及网络端口流量数据。其中网络端口流量数据是由端口流量探测任务采集并更新的本地变量，而进程探测任务也会将扫描到的最新的端口列表更新到端口流量探测任务的本地变量。 如果应用是部署在容器上的，则还会有对应的容器信息采集。最后进程探测任务会将采集到的进程数据更新到心跳客户端的本地变量，随着每次心跳数据的生成被一起采集并上报。 进程数据的采集分别来自以下数据源： 系统命令：包括CPU、内存、连接数等（top等命令）/proc目录下各进程子目录：包括CPU、内存等信息、磁盘读写等信息执行脚本：包括Linux环境下的端口流量数据采集第三方工具包：包括win环境下的端口流量数据采集（JPcap）五、HM处理心跳数据和容器数据在通过Http上送到HM端之后，会由HM端对应的服务进行处理。 HM在启动时会启动自己的心跳客户端，负责发送本机的心跳数据和采集HM所在容器的监控数据。同时还会启动一个心跳服务，负责接收处理所有上送的心跳和容器数据信息。 心跳服务在收到心跳数据请求后，会根据HM的配置，判定当前的HM是不是Master节点。如果HM是Master节点，心跳服务会从Http携带的报文中拿出上报的数据，取得上报节点中的可用服务用于更新服务发现信息，之后将数据存入后端的Redis缓存中；如果不是Master节点，则会将数据移交至本机的心跳客户端，由其下次发送心跳时一起上送。 这样的设计是考虑到大规模监控时会有跨机房的情况存在，此时各监控节点往往不在同一个网段内，通过将同一个网段内的机器上交到边界的“网关”统一上交可解决这一问题。此时的HM即充当着“网关”这一角色。 HM在启动的时候同时还会启动一个定时任务，这个任务负责处理各节点的存活状况。任务定时从Redis中读取全部心跳数据，依次检查上送心跳数据中的客户端时间戳与当前系统时间戳的差值。 当时间超过一定的上送时间间隔之后，更改对应的节点存活状态。当超过一倍上送时间间隔，意味节点可能死亡，处于dying状态。当超过两倍时间间隔时，意味着节点已经死亡。当超过三倍时间间隔时，心跳服务会删除该节点的缓存记录。 随心跳一起上报的容器和进程数据会随着心跳数据一同被存入Redis中，后续由HM的其他定时任务读取并发送给预警中心进行处理，最终监控指标被格式化成特定的结构存入OpenTSDB。 同时采集的容器数据和进程数据会提供前端AppHub查看界面，如图所示： 点击页面上的每一个节点，可以查看详细的节点信息，包括节点的操作系统信息、JVM信息、提供的服务和安装的Feture等等。这些也就是前文所说的随心跳数据上报的那部分信息。如图所示： 六、总结心跳是微服务架构基础但重要的机制，通过定时发送心跳数据，MA节点报告了自身的存活状态，使得HM能够知晓当前系统的运行状态。 同时，UAVStack的心跳数据还同时负责上报节点的容器及进程监控数据，随着这些数据的上报，HM可以对监控的容器和进程做出预警，也能够在前端实时看到应用容器和进程的运行状态。 官方网站：https://uavorg.github.io/main/ 开源地址：https://github.com/uavorg 作者：张明明 来源：宜信技术学院

文章来源：www.liangsonghua.me作者介绍：京东资深工程师-梁松华，长期关注稳定性保障、敏捷开发、JAVA高级、微服务架构 收到研发反馈，TCP重传严重。主机报文重传是TCP最基本的错误恢复功能，它的目的是防止报文丢失 报文丢失的可能因素有很多种 1、 网络设备或线路故障案例：设备接口常常出现的CRC数据校验错误特点：问题一直持续，所有经过该节点的数据都受影响，影响服务器数量大2、 数据路径上的流量突发导致链路拥塞案例：专线打满导致丢包严重特点：突发性极强，持续时间短。更多时候有周期性。所有经过该节点的数据都受影响，影响服务器数量大3、 客户端服务器故障案例：某服务器网卡故障，或者性能下降特点：故障长时间持续，仅仅影响单台设备4、 服务器端服务器故障案例：某服务器网卡故障特点：故障长时间持续，所有请求到该节点的数据都受影响，影响服务器数量大5、 服务器端性能下降案例：有运营活动的时候服务端请求量太大，导致性能下降特点：突发，如果服务端有巨量请求会有周期性，所有请求到这台设备(集群)的数据都有可能受影响，影响服务器数量大6、 代理节点或者VIP性能下降案例：某一负载均衡集群故障或性能下降特点：突发，有周期性。所有请求到该节点的数据都受影响，影响服务器数量大先抓包生成pcap文件，tcpdump -i nsdb475e5d-86 -vvv -w tcp_retry.pcap，保留证据要紧，同时留意值班群和网络应急响应群是否有相同的反馈，如果有其他人反馈，及时确认受影响范围，服务器是否有一些共性，比如集中在某个数据中心上、某个POD下、某台物理机上 使用以下命令实时可以观察系统中每秒tcp重传报文数量，线上监控工具推荐使用阿里出品的tsar-Taobao System Activity Reporter nstat -z -t 1 | grep -e TcpExtTCPSynRetrans -e TcpRetransSegs -e TcpOutSegs -e TcpInSegs 使用netstat -s查看整体情况，按各个协议进行统计结果如下 ss -anti |grep -B 1 retrans查看重传统计情况，具体到IP+端口，这里方便显示使用ss -tanl演示 1、 LISTEN 状态：这两个值表示的是最大的listen backlog积压数值，这里显示为0，实际上会取内核参数net.core.somaxconn的值 2、 其他状态：(1)、 recv-Q:表示网络接收队列，表示收到的数据已经在本地接收缓冲，但是还有多少没有被进程取走，如果短暂不为0，可能是处于半连接状态，如果接收队列Recv-Q一直处于阻塞状态，可能是遭受了拒绝服务 denial-of-service 攻击(2)、send-Q:表示网路发送队列，对方没有收到的数据或者说没有Ack的,还是在本地缓冲区.如果发送队列Send-Q不能很快的清零，可能是有应用向外发送数据包过快，或者是对方接收数据包不够快非LISTEN状态下则通常应该为0，如果不为0可能是有问题的，packets在两个队列里都不应该有堆积状态，可接受短暂的非0情况 ulimit -a检查服务打开的文件句柄上限,10多万正常是足够的 通过ifconfig查看网卡是否存在持续drop、error现象 容器状态正常，开始使用wiresherk分析抓包文件 查看IO graph，确保链路不忙，不忙的链路IO会有很多高低起落，峰值以及空闲间隙 进入Analyze–>Expert Info 查看不同标签下不同级别的提示信息，比如重传的统计、连接的建立和重置统计 ...

服务器192.168.0.248：本地服务器47.56.34.2：远程服务器目的将远程服务器数据同步到本地服务器 前提两台服务器安装rsync和crontabsyum install -y rsyncyum install -y crontabs设置免密登陆在本地服务器中执行# 产生keyssh-keygen -t rsa# 拷贝到远程服务器ssh-copy-id -i /root/.ssh/id_rsa.pub "-p22 root@47.56.34.2"# 免密登陆ssh -p 22 root@47.56.34.2执行命令进行文件同步rsync -vzrtopg --progress --delete -e 'ssh -p 22' root@47.56.34.2:/root/fileUpload /home/backup/fileUpload/# 输出日志rsync -vzrtopg --progress --delete -e 'ssh -p 22' root@47.56.34.2:/root/fileUpload /home/backup/fileUpload/ 1> /home/logs/rsync.log 2>&1采用crond定时同步# 在本地服务器上，定时同步0 2 * * * root /home/backup/script/auto_rsync.sh# 在远程服务器上，定时备份数据库0 2 * * * root /root/backup/script/auto_mysqldump.sh同步脚本备份数据库脚本auto_mysqldump.sh#!/bin/bashDATE="$(date +%F)"backup_dir=/root/backup/databasemysqldump -uroot -pAsdf@123 pms > ${backup_dir}/pms-${DATE}.sql# 只保留前100个lPkgList=($(ls "${backup_dir}" | sort -nr))for ((j=100; j<${#lPkgList[@]}; ++j)); do rm -rf "${backup_dir}/${lPkgList[$j]}"done备份文件脚本auto_rsync.sh#!/bin/bashrsync -vzrtopg --progress --delete -e 'ssh -p 22' root@47.56.34.2:/root/fileUpload /home/backup/fileUpload/ 1> /home/logs/rsync.log 2>&1 rsync -vzrtopg --progress --delete -e 'ssh -p 22' root@47.56.34.2:/root/backup/database /home/backup/database/ 1> /home/logs/rsync-database.log 2>&1 命令详细使用方法http://man.linuxde.net/rsync-v, --verbose 详细模式输出。-q, --quiet 精简输出模式。-c, --checksum 打开校验开关，强制对文件传输进行校验。-a, --archive 归档模式，表示以递归方式传输文件，并保持所有文件属性，等于-rlptgoD。-r, --recursive 对子目录以递归模式处理。-R, --relative 使用相对路径信息。-b, --backup 创建备份，也就是对于目的已经存在有同样的文件名时，将老的文件重新命名为~filename。可以使用--suffix选项来指定不同的备份文件前缀。--backup-dir 将备份文件(如~filename)存放在在目录下。-suffix=SUFFIX 定义备份文件前缀。-u, --update 仅仅进行更新，也就是跳过所有已经存在于DST，并且文件时间晚于要备份的文件，不覆盖更新的文件。-l, --links 保留软链结。-L, --copy-links 想对待常规文件一样处理软链结。--copy-unsafe-links 仅仅拷贝指向SRC路径目录树以外的链结。--safe-links 忽略指向SRC路径目录树以外的链结。-H, --hard-links 保留硬链结。-p, --perms 保持文件权限。-o, --owner 保持文件属主信息。-g, --group 保持文件属组信息。-D, --devices 保持设备文件信息。-t, --times 保持文件时间信息。-S, --sparse 对稀疏文件进行特殊处理以节省DST的空间。-n, --dry-run现实哪些文件将被传输。-w, --whole-file 拷贝文件，不进行增量检测。-x, --one-file-system 不要跨越文件系统边界。-B, --block-size=SIZE 检验算法使用的块尺寸，默认是700字节。-e, --rsh=command 指定使用rsh、ssh方式进行数据同步。--rsync-path=PATH 指定远程服务器上的rsync命令所在路径信息。-C, --cvs-exclude 使用和CVS一样的方法自动忽略文件，用来排除那些不希望传输的文件。--existing 仅仅更新那些已经存在于DST的文件，而不备份那些新创建的文件。--delete 删除那些DST中SRC没有的文件。--delete-excluded 同样删除接收端那些被该选项指定排除的文件。--delete-after 传输结束以后再删除。--ignore-errors 及时出现IO错误也进行删除。--max-delete=NUM 最多删除NUM个文件。--partial 保留那些因故没有完全传输的文件，以是加快随后的再次传输。--force 强制删除目录，即使不为空。--numeric-ids 不将数字的用户和组id匹配为用户名和组名。--timeout=time ip超时时间，单位为秒。-I, --ignore-times 不跳过那些有同样的时间和长度的文件。--size-only 当决定是否要备份文件时，仅仅察看文件大小而不考虑文件时间。--modify-window=NUM 决定文件是否时间相同时使用的时间戳窗口，默认为0。-T --temp-dir=DIR 在DIR中创建临时文件。--compare-dest=DIR 同样比较DIR中的文件来决定是否需要备份。-P 等同于 --partial。--progress 显示备份过程。-z, --compress 对备份的文件在传输时进行压缩处理。--exclude=PATTERN 指定排除不需要传输的文件模式。--include=PATTERN 指定不排除而需要传输的文件模式。--exclude-from=FILE 排除FILE中指定模式的文件。--include-from=FILE 不排除FILE指定模式匹配的文件。--version 打印版本信息。--address 绑定到特定的地址。--config=FILE 指定其他的配置文件，不使用默认的rsyncd.conf文件。--port=PORT 指定其他的rsync服务端口。--blocking-io 对远程shell使用阻塞IO。-stats 给出某些文件的传输状态。--progress 在传输时现实传输过程。--log-format=formAT 指定日志文件格式。--password-file=FILE 从FILE中得到密码。--bwlimit=KBPS 限制I/O带宽，KBytes per second。-h, --help 显示帮助信息。问题遇到ssh修改了默认的端口22不能免密钥登录解决方法： ...

服务不停歇，运维不休息。 7x24 小时连轴转已成为运维工程师的常态，故而每年的 7 月 24 日被视为运维日，代表着运维全天候的保障系统稳定、维护业务正常运行、时刻准备着一线工作的召唤。 腾讯运维技术开放日是由 CODING、腾讯云、TEG 技术工程事业群共同发起，面向运维人员的技术开放日。旨在分享和交流腾讯内部在运维方面的实践经验，打造腾讯内部与外部共同交流、共同进步的运维技术生态。 此次举办的首届腾讯运维技术开放日，将邀请四位在运维及 DevOps 方面有丰富经验的演讲嘉宾，为大家分享他们对运维工作，以及在新时代下关于运维发展的独特见解，共同打造一场运维盛宴。 活动时间和地点时间：2019 年 7 月 21 日 地点：腾讯滨海大厦北塔 3F 多功能厅 报名方式：点击即可报名参加活动 活动福利：20 日前 转发活动至朋友圈，在活动当天签到时出示朋友圈转发，即可获赠 CODING 周边小洋葱猴一只 活动议程13:00 - 13:30 签到 & 自由交流 & 展区体验13:30 - 13:45 开场致辞13:45 - 14:30 《DevOps 理念下运维与开发的新关系》——张海龙 CODING 创始人14:30 - 15:15 《Serverless DevOps 最佳实践》——张远哲 腾讯云中间件产品经理15:15 - 15:30 茶歇交流15:30 - 16:15 《把大象搬上云端 - 腾讯海量业务上公有云历程》——周小军 腾讯自研上云项目负责人16:15 - 17:00 《机器学习在数据中心探索实践之路》——岳上 腾讯 TEG 技术发展中心副总监17:00 - 18:00 自由交流 & 展区体验讲师及议题介绍DevOps 理念下运维与开发的新关系 演讲嘉宾：CODING 创始人张海龙，技术创业者。2014 年创办 CODING，为企业用户提供 SaaS 软件研发管理工具，将在线 IDE、代码托管、持续集成、制品管理等工具一体化，让整个开发过程都可以在浏览器中实现。 议题简介：CODING 深耕 DevOps 市场，除腾讯外，也为富士康、拉卡拉、国泰证券、天津大学等组织提供 DevOps 工具服务。本次将分享协助客户进行 DevOps 转型的经验，在 DevOps 的大趋势下开发与运维的新关系。 ...

什么是运维编排服务？阿里云运维编排服务（Operation Orchestration Service，简称OOS）是云上的自动化运维平台，提供运维任务的管理和执行。典型使用场景包括：事件驱动运维，批量操作运维，定时运维任务，跨地域运维等，OOS为重要运维场景提供审批，通知等功能。OOS帮用户实现标准化运维任务，从而实践运维即代码（Operations as Code）的先进理念。OOS支持跨产品使用，用户可以使用OOS管理ECS、RDS、SLB、VPC等云产品。 用大白话讲，就是阿里云的用户编写一个包含运维逻辑的模板，提交给OOS，然后OOS在云端，以用户的身份执行这个模板里面的运维逻辑。 阿里云OOS的公共模板已经开源在github 更多的信息请参考之前的文章 阿里云重磅发布云上自动化利器——运维编排OOS或参考运维编排官方帮助文档 权限相关的三个基本概念：用户，授权策略，角色先说用户，用户就是账号，这个概念很好理解。用户分为两类：主账号和子账号。 阿里云上的用户在最开始使用阿里云服务的时候，都会注册一个云账号，这个注册生成的账号就叫做主账号，可以理解为root账号，拥有最高的权限。 接下来，拥有主账号的用户如果想要创建子账号，就需要开通一个叫做RAM (Resource Access Management)的云产品。开通RAM之后，就可以在RAM控制台上，创建子账户。 创建子账户的目的，是为了限制子账户的权限，避免root账户被滥用和泄露的风险。 那么，子账户的权限如何限制呢？这儿就要先引入授权策略的概念。授权策略表示一组权限的集合，比如针对ECS的创建销毁启停的权限集合。授权策略也分两类，一类是阿里云内置的系统授权策略，另一类是用户自定义的授权策略。OOS服务默认包含了两个系统授权策略，一个叫做OOSFullAccess，相当于拥有了OOS这个服务的全部权限，另一个叫做OOSReadOnlyAccess，相当于只能读取OOS的模板和历史执行的数据，不能做修改模板也不能启动执行。 账号和授权策略之间，是多对多的关系。主账户或者管理员，可以决定，每一个子账号拥有哪些权限策略。比如，给user1分配OOSFullAccess权限策略，而给user2分配OOSReadOnlyAccess权限策略。 那么，什么是角色（Role）呢？角色是一种虚拟的用户，它不对应任何可以控制台登录的账户，但主账号或管理员可以创建Role并给Role像普通用户一样赋予授权策略。那么谁来使用这些虚拟用户（Role）呢？典型的使用场景就是云产品。主账户或者管理员，可以为角色配置“信任关系”，也就是可以决定哪些云产品能够使用这些虚拟账户。 权限问题1：Assume RoleOOS的核心功能，是要按照用户的身份去执行用户提前编写好的模板。这里面就涉及到了一个基本问题：OOS作为一个云产品，用什么样的身份去执行用户编写的模板呢？ 如果单从简单实现的角度，而不考虑安全，那么阿里云直接给OOS赋予一个超级权限就可以了，反正是“自家”产品。这样做可以吗？我们认为不可以。用户需要有能力对OOS进行限制，需要可以决定OOS可以操作哪些资源，不可以操作哪些资源。也就是说，OOS在执行用户的模板的时候，一定是“扮演”了某个用户可控的身份。 相信聪明的读者已经想到了，这里用到了前面介绍的角色（Role），以及Assume Role这个功能。Assume Role，就是云产品，扮演用户的某个角色。用户，需要进行两个操作步骤：第一步，就是创建一个角色（Role），并且信任运维编排服务，如下图所示： 第二步，就是给这个角色赋予权限策略，用户如果希望OOS来管理ECS，就可以考虑把AliyunECSFullAccess这个权限策略赋予给这个角色。 那么，接下来，OOS是怎么Assume Role执行模板的呢？ 在OOS模板里面，可以通过“RamRole”这个字段指定一个角色，OOS在后台执行这个模板的时候，就会尝试扮演这个Role。如果模板没有指定，那么OOS就会尝试扮演默认的角色，也就是OOSServiceRole这个角色。 FormatVersion: OOS-2019-06-01RamRole: 'OOSServiceRole'Tasks:- Name: describeRunningInstancesByTag Action: ACS::ExecuteApi Description: Views running ECS instances by specifying tag. Properties: Service: ECS API: DescribeInstances Parameters: Status: Running Tags: - Key: 'tagkey' Value: 'tagvalue'如果用户没有预先创建相应的角色，那么在执行的时候，就会报错，错误消息类似于“：Assumes role failed. Code: EntityNotExist.Role, msg: The role not exists: acs::111111:role/OOSServiceRole.” ...

场景简介我们经常会有这样的运维场景，扩容一批机器需要配置SLS日志，对于已经配置好的SLS Logstore后，我们只需要将机器加到机器组里。 解决方案传统的解决方案是登录每台ecs实例并安装logtail，执行的命令为 wget http://logtail-release-{{ACS::RegionId}}.oss-{{ACS::RegionId}}-internal.aliyuncs.com/linux64/logtail.sh -O logtail.sh; chmod 755 logtail.sh; ./logtail.sh install {{ACS::RegionId}};echo {{ LogTailUserDefinedId }} > /etc/ilogtail/user_defined_id分解下Task，需要以下几步:1.检查实例是不是Running状态2.调用云助手CreateCommand创建上述命令3.调用InvokeCommand执行4.等待执行成功5.删除模板 再转换成OOS模板并创建命名为installSlsAgent { "FormatVersion": "OOS-2019-06-01", "Description": "Install Logtail agent on the ECS Instance.", "Parameters": { "InstanceId": { "Type": "String", "Description": "the Instance Id to install ilogtail", "AllowedPattern": "i-[A-Za-z0-9]*", "MinLength": 1, "MaxLength": 30 }, "LogTailUserDefinedId": { "Type": "String", "Description": "the user defined Id write to /etc/ilogtail/user_defined_id", "AllowedPattern": "[A-Za-z0-9\\-_]*", "MinLength": 1, "MaxLength": 30 }, "OOSAssumeRole": { "Type": "String", "Description": "The RAM role to be assumed by OOS.", "Default": "OOSServiceRole" } }, "RamRole": "{{OOSAssumeRole}}", "Tasks": [ { "Name": "checkInstanceReady", "Action": "ACS::CheckFor", "Description": "describe instances with specified parameters, refer them here: https://help.aliyun.com/document_detail/63440.html", "Properties": { "API": "DescribeInstances", "Service": "ECS", "PropertySelector": "Instances.Instance[].Status", "DesiredValues": [ "Running" ], "Parameters": { "InstanceIds": [ "{{ InstanceId }}" ] } }, "Outputs": { "InstanceIds": { "ValueSelector": "InstanceIdSets.InstanceIdSet[]", "Type": "List" } } }, { "Name": "createCommand", "Action": "ACS::ExecuteApi", "Description": "create the command to install logtail agent.", "Properties": { "API": "CreateCommand", "Service": "ECS", "Parameters": { "CommandContent": { "Fn::Base64Encode": "wget http://logtail-release-{{ACS::RegionId}}.oss-{{ACS::RegionId}}-internal.aliyuncs.com/linux64/logtail.sh -O logtail.sh; chmod 755 logtail.sh; ./logtail.sh install {{ACS::RegionId}}; echo {{ LogTailUserDefinedId }} > /etc/ilogtail/user_defined_id" }, "Name": "oos-{{ACS::TemplateName}}", "Type": "RunShellScript" } }, "Outputs": { "CommandId": { "Type": "String", "ValueSelector": "CommandId" } } }, { "Name": "invokeCommand", "Action": "ACS::ExecuteApi", "Description": "invoke the command to install ilogtail", "Properties": { "Service": "ECS", "API": "InvokeCommand", "Parameters": { "CommandId": "{{ createCommand.CommandId }}", "InstanceIds": [ "{{ InstanceId }}" ] } }, "Outputs": { "InvokeId": { "Type": "String", "ValueSelector": "InvokeId" } } }, { "Name": "untilInvocationDone", "Action": "ACS::WaitFor", "Description": "until invocation ready", "MaxAttempts": 5, "Properties": { "Service": "ECS", "API": "DescribeInvocations", "Parameters": { "InvokeId": "{{ invokeCommand.InvokeId }}" }, "DesiredValues": [ "Finished" ], "PropertySelector": "Invocations.Invocation[].InvokeStatus" } }, { "Name": "describeInvocationResult", "Action": "ACS::ExecuteApi", "Description": "get the command invocation result", "Properties": { "Service": "Ecs", "API": "DescribeInvocationResults", "Parameters": { "InvokeId": "{{ invokeCommand.InvokeId }}" } }, "Outputs": { "InvocationResult": { "Type": "String", "ValueSelector": "Invocation.InvocationResults.InvocationResult[].Output" }, "ExitCode": { "Type": "Number", "ValueSelector": "Invocation.InvocationResults.InvocationResult[].ExitCode" } } }, { "Name": "deleteCommand", "Action": "ACS::ExecuteAPI", "Description": "clean up the install ilogtail command", "Properties": { "Service": "ECS", "Risk": "Normal", "API": "DeleteCommand", "Parameters": { "CommandId": "{{ createCommand.CommandId }}" } } } ], "Outputs": { "InvocationResult": { "Type": "String", "Value": { "Fn::Base64Decode": "{{ describeInvocationResult.InvocationResult }}" } }, "ExitCode": { "Type": "String", "Value": "{{ describeInvocationResult.ExitCode }}" } }}以上模板我们很好的解决了单台机器执行Install sls Agent的任务，那么对于多台机器的执行怎么办呢？OOS的Loop功能可以很好的解决这个问题。并且OOS支持模板嵌套执行，那么我们只需要构建一个传入实例ID列表的 ...

环境:centos7 1.通过开机修改内核引导重置重启linux系统主机并出现引导界面时，按下E键进入内核编辑界面在linux16参数这行的最后追加"rd.break"参数，然后按下Crtl + X 来运行修改过的内核参数之后，系统进入紧急救援模式输入以下命令，等待系统重启即可完成修改 mount -o remount,rw /sysrootchroot /sysrootpasswdtouch /.autorelabelexitreboot 2.通过光盘救援模式修改开机时选光驱引导，选Troubleshooting,后选择Rescue a Centos system,选1继续，进入救援模式进入救援模式后，此时系统已被挂载到/mnt/sysimage路径上，我们可以通过修改原系统的/etc/shadow文件来重置root密码 vi /mnt/sysimage/etc/shadow将shadow文件第一行root的第二个字段删除，然后wq!保存重启系统，此时root可以无密码登录，再用passwd命令创建密码即可

对，你没看错，本文就是教你怎么写出让同事无法维护的代码。对于有下面这些编程习惯的朋友，请大家对号入座。 程序命名 容易输入的变量名。比如：Fred，asdf... 单字母的变量名。比如：a,b,c, x,y,z（如果不够用，可以考虑a1,a2,a3,a4,….） 有创意地拼写错误。比如：SetPintleOpening，SetPintalClosing。这样可以让人很难搜索代码。 抽象。比如：ProcessData, DoIt, GetData… 抽象到就跟什么都没说一样。 缩写。比如：WTF，RTFSC …… （使用拼音缩写也同样给力，比如： BT，TMD，TJJTDS） 随机大写字母。比如：gEtnuMbER... 重用命名。在内嵌的语句块中使用相同的变量名有奇效。 使用重音字母。比如：int ínt（第二个 ínt不是int） 使用下划线。比如：_, __, ___。 使用不同的语言。比如混用英语，德语，或是中文拼音。 使用字符命名。比如：slash, asterix, comma… 使用无关的单词。比如：god, superman, iloveu…. 混淆l和1。字母l和数字1有时候是看不出来的。 伪装欺诈 把注释和代码交织在一起。 for(j=0; j<array_len; j+ =8){ total += array[j+0 ]; total += array[j+1 ]; total += array[j+2 ]; / Main body of total += array[j+3]; loop is unrolled total += array[j+4]; for greater speed. total += array[j+5]; / total += array[j+6 ]; total += array[j+7 ];}代码和显示不一致。比如，你的界面显示叫postal code，但是代码里确叫 zipcode。 ...

“故障注入 Sidecar“——为您的微服务注入故障以验证集群性能! 由于导师和实验室师兄们的科研需要，本人专门以 Sidecar的模式设计了一个用于错误注入的微服务模块。该模块可以与任何微服务应用共同部署运行，为其模拟cpu、内存等错误。 本项目的 Github地址: https://github.com/iscas-micr...我的联系方式: leontian1024@gmail.com || 或直接留言 欢迎您提出问题批评指点!项目背景目前，本人正在中科院软件所的微服务研究组从事部分研究工作。由于本人所在科研小组的研究内容( 微服务自动扩缩容相关 )，需要经常使微服务应用处于"高 CPU 利用率" 和 "高内存使用"的状态。因此，为了方便导师和实验室的各位师兄进行实验，本人特地开发了一个可以注入进 Pod 中的错误注入容器，来模拟上述的高负载状态。 导师和师兄们使用后对我的工作给予了肯定，因此我准备将开发过程和简单使用方法写成文章做个记录( 也就是本文 )，一来方便自己日后工作学习，二来也方便有类似实验需求的其他同仁们使用这个小项目，为大家的研究节省时间。更具体的安装和使用方法，可以移步本项目 Github 的代码仓库，其中有非常详细的说明。 知识储备什么是微服务中的"Sidecar 运行模式?" 上图: 以 Sidecar 模式部署并运行的微服务单元Sidecar 运行模式是最近两年比较火的一种微服务部署和运行方法，它由目前流行的 ServiceMesh(服务网格) 架构推广而来。 具体而言，Sidecar 运行模式是一种"将不属于业务应用的功能以独立的容器运行于业务容器旁边"，在 K8s 中表现出的样子就是将具有不同功能的模块封装成不同的镜像，并以不同的容器运行在同一个 Pod 中。这种说法非常形象，因为 Sidecar 这个单词的本意就是三轮摩托侧面的"跨斗"，这里形容独立于业务应用但又与业务应用部署在一起非常合适。 上图: Sidecar ，中文意思为摩托车的跨斗，不由赞叹命名的非常生动主要设计思想架构设计本项目的错误注入模块也采用了 Sidecar 这种设计思想，将用于模拟 CPU、内存等故障的模块独立封装成一个镜像，并在 Pod 启动时以 Sidecar 的形式运行在主业务容器旁边。这样，不用它时他就会安安静静地当个美男子，完全不用担心它会影响到正常业务的运行；一旦需要它模拟错误产生，由于与业务容器同处于一个 Pod 之中(而 K8s 又以 Pod 为基本单元)，因此他模拟出的错误亦被 K8s 集群视为业务应用所在 Pod 产生而被监测到。 上图: Pod 中的每个容器都有自己的端口映射到外部主机，因此不会相互影响注入方式设计本项目在设计之初是采用“在容器内修改环境变量”的方式对容器注入故障的，但事实证明这种方法太low，而且非常麻烦。因此在后续设计和实现中采用了目前较为流行的通过 REST API 传递 POST 请求的方式使容器模拟错误，这样就极大地方便了师兄们展开实验，而且也可以模拟出“微服务间调用而产生错误”的场景( 上游服务调用错误注入的 API 而模拟下游服务产生错误 )。 ...

第一篇 awk简介与表达式实例一种名字怪异的语言模式扫描和处理，处理数据和生成报告。awk不仅仅是linux系统中的一个命令，而且是一种编程语言；它可以用来处理数据和生成报告（excel）；处理的数据可以是一个或多个文件；可以是直接来自标准输入，也可以通过管道获取标准输入；awk可以在命令行上直接编辑命令进行操作，也可以编写成awk程序来进行更为复杂的运用。 sed处理stream editor文本流，水流。 一、awk环境简介本文涉及的awk为gawk，即GNU版本的awk。 [root@creditease awk]# cat /etc/redhat-releaseCentOS Linux release 7.5.1804 (Core)[root@creditease awk]# uname -r3.10.0-862.el7.x86_64[root@creditease awk]# ll `which awk`lrwxrwxrwx. 1 root root 4 Nov 7 14:47 /usr/bin/awk -> gawk [root@creditease awk]# awk --versionGNU Awk 4.0.2二、awk的格式awk指令是由模式、动作，或者模式和动作的组合组成。 模式即pattern，可以类似理解成sed的模式匹配，可以由表达式组成，也可以是两个正斜杠之间的正则表达式。比如NR==1，这就是模式，可以把它理解为一个条件。动作即action，是由在大括号里面的一条或多条语句组成，语句之间使用分号隔开。如下awk使用格式。三、记录和域名称含义record记录，行filed域，区域，字段，列1）NF（number of field）表示一行中的区域（列）数量，$NF取最后一个区域。 2）$符号表示取某个列（区域），$1,$2,$NF 3）NR (number of record) 行号,awk对每一行的记录号都有一个内置变量NR来保存，每处理完一条记录NR的值就会自动+1 4）FS（-F）field separator 列分隔符，以什么把行分隔成多列 3.1 指定分隔符[root@creditease awk]# awk -F "#" '{print $NF}' awk.txt GKL$123GKL$213GKL$321[root@creditease awk]# awk -F '[#$]' '{print $NF}' awk.txt 1232133213.2 条件动作基本的条件和动作[root@creditease awk]# cat awk.txt ABC#DEF#GHI#GKL$123BAC#DEF#GHI#GKL$213CBA#DEF#GHI#GKL$321[root@creditease awk]# awk -F "#" 'NR==1{print $1}' awk.txtABC3.3 只有条件 [root@creditease awk]# awk -F "#" 'NR==1' awk.txtABC#DEF#GHI#GKL$123默认会有动作{print $0} ...

一 前言MySQL 主从架构已经被广泛应用,保障主从复制关系的稳定性是大家一直关注的焦点。MySQL 5.6 针对主从复制稳定性提供了新特性: slave 支持 crash-safe。该功能可以解决之前版本中系统异常断电可能导致 relay_log.info 位点信息不准确的问题。本文将从原理，参数，新的问题等几个方面对该特性进行介绍。 二 crash-unsafe在了解 slave crash-safe 之前，我们先分析 MySQL 5.6 之前的版本出现 slave crash-unsafe 的原因。我们知道在一套主从结构体系中，slave 包含两个线程:即 IO thread 和 SQL thread。两个线程的执行进度(偏移量)都保存在文件中。 IO thread 负责从 master 拉取 binlog 文件并保存到本地的 relay-log 文件中。 SQL thread 负责执行重复 sql，执行 relay-log 记录的日志。 crash-unsafe 情况下 SQL_thread 的 的工作模式: START TRANSACTION; Statement 1 ... Statement N COMMIT;Update replication info files (master.info, relay_log.info)IO thread 的执行状态信息保存在 master.info 文件, SQL thread 的执行状态信息保存在 relay-log.info 文件。slave 运行正常的情况下，记录位点没有问题。但是每当系统发生 crash,存储的偏移量可能是不准确的(需要注意的是这些文件被修改后不是同步写入磁盘的)。因为应用 binlog 和更新位点信息到文件并不是原子操作，而是两个独立的步骤。比如 SQL thread 已经应用 relay-log.01 的4个事务 ...

为什么是容器如果问你现在最热门的服务器端技术什么？想必很多人会不假思索的说是容器！ 容器技术实际上并不是一个新鲜的名词，现在大家一提到容器马上想到的就是Docker，但是容器这个词并不是Docker公司发明的，早期的Pass项目如CloudFoundry，其底层就是基于namespace和cgroups的容器技术。 Docker在当时实际上是个小弟，并没有引起大家的注意，但是现在Docker已经成为容器事实上的标准，是什么让Docker发展成现在这样的程度呢？ 这个功能就是Docker镜像。 早期的Pass平台最为人诟病的一个软肋就是应用的打包部署问题，一个应用包在本地部署的好好的，接入Pass平台后却问题重重，而Docker镜像解决了这个根本性问题。 容器到底是怎么回事前面我们说了容器实际上很早以前就有的技术，主要用到的是Linux的namespace，cgroups和rootfs。 我们经常说沙盒或者集装箱，他们里面装的是货物，那容器这个沙盒装的又是什么呢？是进程！ 我们把进程装进一个沙盒(容器)里面，给他制造边界，和盒子外面的世界隔离，所以我们会说容器实际上就是加了围墙的一个进程。 Namespace为进程制造边界就需要用到namespace技术，我们先运行一个docker进程看一下： docker run -it busybox /bin/sh # -it 是提供一个tty的输入输出环境# -d 后台运行程序# -v 挂载外部存储# -p 端口映射# -e 参数变量# busybox 轻量级的容器镜像我们执行ps命令，可以看到有趣的现象，PID为1的就是我们的启动进程。 而实际上在宿主机上面会启动一个进程，其PID在这里是22035。 这就是PID namespace实现的障眼法，它在Linux进程启动的时候（clone函数），会添加CLONE_NEWPID的参数，进程就会看到一个新的命名空间，所以进程ID就会变成1，实际上进程在宿主机上面还是22035。 除了PID namespace之外，还有很多的namespace，比如Network、Mount、User等，通过这些namespace对进程进行网络、储存、文件等进行限制，使这个进程看不到宿主机的真实情况，装在了盒子里，这就是容器的核心原理了。 Cgroups我们通过 Linux 的命名空间为新创建的进程隔离了文件系统、网络、宿主机器上的其他进程，但是命名空间并不能够为我们提供物理资源上的隔离，比如 CPU 或者内存。在同一台机器上可能运行着多个对彼此以及宿主机器一无所知的『容器』，但这些容器却共同占用了宿主机器的物理资源。 如果其中的某一个容器正在执行 CPU 密集型的任务，那么它就会影响其他容器的任务执行效率，导致多个容器相互影响并且抢占资源。如何对多个容器的资源使用进行限制就成了解决进程虚拟资源隔离之后的主要问题，而 Control Group（简称 cgroups）就能隔离宿主机器上的物理资源，例如 CPU、内存、磁盘 I/O 和网络带宽。cgroups介绍、应用实例及原理描述 容器是一个单进程的模型通过namespace和cgroups的学习我们知道了容器就是一个启用了多个namespace的应用进程，而这个进程能够使用的资源受到cgroups的限制。这里面有个很重要的概念：容器是一个单进程的模型。 由于容器本质上面是一个进程，即PID=1的进程，他是后续其他进程的父进程，这就意味着在一个容器内，你没有办法同时运行两个应用，除非找到一个公共的PID=1的父进程，并使用像systemd或者supervisor这样的软件替代PID=1的进程来做为容器的启动进程。 但是我们还是希望容器和应用是同生命周期的，因为如果容器是好的，而里面的进程却已经挂了，这样处理起来就会非常麻烦了。 通过上面对容器原理的了解，我们能不能分析出容器和虚拟机的区别？ 虚拟机需要hypervisor层，在上面创建虚拟机是一个完整的OS容器是Linux上的一个进程虚拟机的OS资源消耗比容器大的多容器使用的是宿主机上相同的内核容器隔离不了时间等资源镜像前面说了Docker能够成为容器现在的事实标准，主要是因为Docker创新了镜像这个东西，那么镜像在Linux系统里面是怎么存在的呢？ 我们Docker的工作目录是/app/docker/docker/ ，其中有个overlay2子目录，它就是我们的镜像目录。 我们在这个目录下有三个目录和一个l的目录，如下: 我们可以进入其中一个目录，并查看该目录下diff子目录的内容: 到这里我们可以知道，镜像是由多个层组织并定义的，这些层本质上是文件，这些文件是只读的，每层具体的文件存放在层标识符下的diff目录下。 所以我们在制作镜像的时候就需要理解层的概念，提高镜像制作的效率和重复使用性。 以我们最常使用的Dockerfile制作镜像举例： FROM node:8.16.0RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtimeRUN echo "Asia/Shanghai" >> /etc/timezoneRUN date -RRUN mkdir -p /opt/app/WORKDIR /opt/appRUN rm -rf /opt/app/node_modules/COPY package.json ./RUN npm install --registry=https://registry.npm.taobao.orgDockerfile 中的每一条命令在最终生成的镜像中都会产生一层。Docker为了提高镜像分发效率，给镜像赋予了复用层的能力，在拉取，推送，build不同镜像时，不同镜像中内容相同的层可以被复用从而节省大量操作。 ...

背景Q 业务系统在做发布前检查工作时，发现一台单机的主日志没有打印，而其他生产机器的日志表现则是正常的。 排查流 思考通过 greys 观察主 service 的业务入口，发现该机器线上流量的请求接受、逻辑处理、结果反馈均正常。排查范围就聚焦在 log jar 配置上。 解决SOF搜索，找到一篇 log 绑定包冲突的排查 & 解决方法。排查本地是否存在绑定包冲突的问题，结果发现确实是的 —— 引入 slf4j-log4j12-empty_version.jar，排掉其他 jar 包引入的日志绑定包。发布、部署该单机，问题解决。原理研究了一下 slf4j-log4j12 实现绑定的原理——简单来说，日志输出到单机本地，需要以下 3 类 jar 包相互配合： slf4j 。业务程序调用的日志接口，只有接口定义，没有实现，从而保证了代码层调用 Log 的统一日志组件。比如 log4j-api、log4j-core，是 log4j2 的内部实现；logback-classic、logback-core，是 logback 的内部实现；log4j，是 logj4 的内部实现。它们本身是没有冲突的，可以并存绑定包。将 slf4j-api 的接口绑定到对应的 log 实现上，比如 slf4j-log4j12、log4j-slf4j-impl（关键） 具体到代码实现上，就是通过 StaticLoggerBinder.getSingleton ( ) 方法返回的单例，实现包的绑定 —— qjt 程序中，同时存在着两类绑定包：log4j-slf4j-impl-2.7.jar 和 slf4j-log4j12-1.7.2.jar。这实际是一种意义上的日志绑定包冲突 —— 选定哪个包，取决于 ClassLoader 先加载哪个，具有一定的随机性。 其他生产机 StaticLoggerBinder 的加载情况 —— 可以看到使用的是 log4j-slf4j-impl-2.7.jar ...

背景应用微服务化场景下，随着服务个数的增加，服务之间的相互调用变得更加复杂，服务治理需求愈加突出，其中服务流量控制是服务治理中的重要一环。 当前常用的流量控制方案主要有基于Spring Cloud的Hystrix和阿里开源的Sentinel应用流量控制降级方案。客观而言，两个方案都是侵入式的，要求用户在应用中引入相关包，编写相关逻辑。 UAVStack作为一套智能化服务技术栈，其服务治理（UAV.ServiceGovern）模块提供了基于画像的服务注册与发现、服务访问授权及服务流量控制能力。 本文主要介绍UAVStack的无侵入式服务流量限制及降级方案。安装UAV后，通过页面配置即可用实现常用的QPS限流等。 一、限流模型 图1限流模型 UAV服务治理流量控制采用上图所示的漏斗+能力池限流模型。将应用根据UAV画像抽象出三层，分别是应用层（应用实例层）、服务组件层和URL层。每一层均可以添加多个限流策略，多个限流策略以“且”的关系存在。请求呈漏斗状依次进入URL层限流、服务组件层限流、应用层限流，只有通过三层限流后才能进入应用。 应用层（应用实例层）：应用层代表当前应用实例整体，应用层限流即限制进入当前应用的总流量。应用层限流流量为服务组件层和URL层流量上限；服务组件层：服务组件层是应用下所有服务组件的集合，包含一个或多个服务组件。可以针对每个服务组件配置不同的限流和降级策略，每个服务组件包含0个或多个URL；URL层：URL层包含所有服务URL。URL层限流即限制进入具体URL的流量。流量控制的目标不是仅仅限制QPS，还要限制对系统资源的使用。服务能力池描述当前应用或组件对外提供的服务能力的上限，该上限为池的最大容量；由于不同的请求消耗的系统资源不一样，因此每种类型的请求将会被赋予不同的权重值。重的请求消耗更多系统资源，将被赋予更大的权重值，而轻的请求赋予较小的权重值。每个请求都会根据权重值消耗服务能力池中的能力，重的请求比轻的请求消耗得服务能力多。无法从服务能力池中获取足够的服务能力时，便会触发降级策略。 二、关键技术2.1 MOF中间件劫持MOF(MonitorFramework)中间件劫持为UAV服务治理中流量控制提供基础支撑。主要提供以下几方面的支撑： 请求捕获：捕获所有进入应用容器的请求，并将请求转入限流模型处理流程，实现流量控制和请求降级；流量控制策略配置：基于MOF提供的基础能力实现流量控制策略配置、当前限流状态查询/开启/关闭等热控制。2.2 限流器和降级策略UAV服务治理默认支持两种限流器：时间段计数限流器和基于令牌桶算法的服务能力限流器。 时间段计数限流器通过原子量累计时间段内请求个数。当请求个数超过限制总数时，执行降级策略。默认的降级策略是终止请求处理流程，返回TOO_MANY_REQUEST。UAV服务治理支持开发和配置自定义的降级策略。 基于令牌桶算法的服务能力限流器会随着时间变化按恒定时间间隔(1/QPS，如果QPS=100,则间隔是10ms)向服务能力池中里补充，直至将能力池填满。出现新请求时，会根据当前请求权重值N拿走N个Token；如果没有足够的Token可取，则会阻塞或拒绝请求，从而执行拒绝策略。基于令牌桶算法的服务能力限流器也支持开发和配置自定义的降级策略。 UAV服务治理不仅支持自定义降级策略，也支持自定义限流器，满足不同用户的不同需求。 三、功能展示3.1 限流策略配置树页面根据应用画像以配置树形将应用展示为三层：应用实例层、服务组件层、URL组件层。如图2所示，应用实例层节点代表当前应用实例（仅有一个）；服务组件节点代表当前应用下的某一具体服务组件，如RS服务组件，每个服务组件下可能包含0个或多个URL节点；一个URL节点代表应用对外提供的服务的具体URL。 流量控制策略可以配置在三层中的任意节点上。配置在应用实例层节点可以限制进入整个应用的流量；配置在服务组件节点上可以控制当前服务组件下所有URL的流量；配置在URL节点上可以限制访问当前URL的流量。 图2 应用配置树 3.2 策略配置及策略下发策略配置中主要配置限流器、限流器参数、降级策略及降级策略参数。默认限流器是基于令牌桶算法的服务能力限流器，URL节点需要配置限流阈值和当前节点的请求权重值。请求超过阈值时，默认降级策略会返回TOO_MANY_REQUEST。 图3 策略配置 配置策略完成，通过策略下发按钮将策略下发至目标应用，同时展示当前实时限流状态。 图4 策略下发结果状态展示 3.3 限流效果及性能展示图5为极简应用（接收到请求后直接返回）场景下的测试结果，包括在压力不断增强的情况下应用原生吞吐量（红线）、安装UAV不启用限流的吞吐量（黑线）、安装UAV限流900QPS时应用接收到的请求量（限流900整体，蓝线）、限流900QPS时正常处理的请求量（橙线，限流900正常请求）及限流900QPS时拒绝的请求量（绿线，限流900限流请求）。 图5 应用吞吐量测试 从图5中可以看出，对比原生和安装UAV无限流情况，UAV限流对应用的吞吐量影响比较小，基本可以忽略不计。随着请求量的增加，进入应用的正常请求量（橙线）稳定在900左右，被限流的请求量随着整体请求量增加而增加，且与未被限流的请求量之和为整体请求量，表明UAV限流有效。另一方面，随着请求量的增加，在原生和无限流的情况下，应用吞吐量在1500左右达到上限；但在限流900QPS的情况下，应用请求量一直在增加，因为超出的请求被直接拒绝，没有进入应用中，从侧面体现了UAV限流对应用的保护能力。 图6为极简应用场景的测试结果，为应用在压力不断增强的情况下的平均响应时间。在原生和无限流情况下（红线和黑线），应用的平均响应时间随着压力增大而增加，最终在1300左右时大幅增加，说明应用的服务能力已经接近极限；在UAV限流900QPS的情况，正常请求（橙线）的平均响应时间即使超过1300达到2100时也基本保持稳定，被拒绝的请求的平均响应时间未见大幅变动，应用服务器的平均响应时间也基本保持稳定。UAV限流对应用实现了有效保护。 图6 应用平均响应时间测试 总结服务治理是微服务化场景下的一个重要问题。本文仅简单介绍UAV服务治理中服务端限流部分原理和功能展示。由于篇幅有限，暂不详细展开介绍。大家有兴趣可以继续关注UAVStack公众号或申请加入官方微信群，相信您一定会有所收获。 官方网站：https://uavorg.github.io/main/ 开源地址：https://github.com/uavorg UAVStack已在Github上开放源码，并提供了安装部署、架构说明和用户指南等双语文档，欢迎访问-给星-拉取~~~ 作者：曾礼 原文发布于：UAVStack智能运维

出品 | 滴滴技术作者 | 陶文 前言：本文来自陶文老师在内部发布的话题分享，引发了技术桔们的热议，桔妹在此与大家分享该话题，期待大家看完陶老师的解读，在文末分享自己对技术深度的看法。 经常有同学被挑战工作没有技术深度。不少日常写业务的同学会顿时紧张起来。开始在脑袋里找各种证据证明自己干过的啥事情“有难度的”。 其实这个问题如果准备一下，就不至于慌张了。在我看来，技术深度可以从下面这张图推导而来： 技术同学的主要工作是构建一个可运行的 solution 去解决用户的一个 problem。以这个为主题，有两件工作： 运营维护这个 solution，持续去解决 problem。 洞察到 problem 本身的变化，或者有更好的 solution。然后把现有的solution迁移成一个新的 solution 去更好的解决 problem。 技术深度就体现在“更好”地完成这两项工作上，也就是一个优化问题： ▍对运营维护工作而言 降低运营的人工成本：例如自动化代替人工。 降低运营的其他成本：例如更少的机器投入，例如稳定性和安全建设减少风险。 ▍对研发工作而言 对 new problem 或者 new solution 的洞察力：数据分析，市场调研，新技术跟进等。提升 solution 对用户的吸引力。新体验-旧体验-迁移成本。 短期敏捷性：因为对 api 很熟悉，能够快速rush出一个版本来的能力。因为对环境很熟悉，可以快速定位 bug 的能力等。 长期敏捷性：架构设计，复杂度管理等。 提供独特 solution 的能力：比如说自动驾驶等科技。从 0 到 1 的过程可以最大化对用户的吸引力，因为很少人提供竞争 solution。 ▍每一项优化工作，都可以做得很深 比如你可以投入大量时间学习数据库原理，优化索引检索的效率，从而降低运营的其他成本。 你也可以构建流量录制和回放技术，提供对重构工作的信心保障。从而提高长期敏捷性。 你也可以打磨对产品的洞察力。精通数据分析，倾听用户，对产品的未来演进方向提供自己的洞察。 你也可以锻炼自己快速 debug 的能力，可以在 crash 之后快速用各种工具找到性能瓶颈。这个算是短期敏捷性上的能力。主要是考验对环境和生态是否熟悉。所谓经验活。 其实评委在问你技术深度的时候，并不是问你技术栈的深度（比如是否从像素渲染到硅的提纯都了然于胸），真正在问的是你的竞争力在哪里。 ▍你需要想清楚两点 为什么在这个点上，我做过的工作证明了比其他同事要更强。 为什么这个能力是当前公司需要的，也就是所谓的收益。你能手写汇编构造 GUI，但是公司不需要也是没有用的“技术深度”。 希望下次你被问到技术深度问题的时候，能够从容回答。 ...

vsftpd服务的搭建环境: 系统centos7ip:10.0.0.51.匿名开放模式yum install vsftpd -y #安装vsftpd服务systemctl start vsftpd #启动服务参数作用anonymous_enable=YES允许匿名访问anon_umask=022匿名用户上传文件的umask值anon_upload_enable=YES允许匿名用户上传文件anon_mkdir_write_enable=YES允许匿名用户创建目录anon_other_write_enable=YES允许匿名用户修改目录名称或删除目录local_root=/var/ftp设置root目录chroot_local_user=YES是否将所有用户限制在主目录anon_root=/var/www匿名用户登录目录通常默认安装的vsftpd就是匿名模式，当我们启动服务后，需要放行相应服务端口,要注意的是，你要是修改了匿名用户目录，目录权限不可以是777，最好是755，登录的主目录匿名用户是无法上传的，在主目录创建目录，修改其权限可写即可上传至该目录 2.本地用户模式本地用户模式可以和匿名模式一起使用，通常环境可以创建一位具有写权限的用户来上传文件，而匿名用户方便大家下载相关资料。编辑/etc/vsftpd/vsftpd.conf local_enable=YESwrite_enable=YESlocal_umask=022将以上三项写入配置文件,然后重启vsftpd服务，默认情况本地用户登录是在自己的家目录，root用户被禁止登录，若有需求可以修改user_list和ftpusers文件将登录权限放开。 3.虚拟用户模式虚拟用户模式是三个模式中最安全的一种验证方式，配置过程也会稍微复杂一些，虚拟用户模式也可以和匿名模式混用。 1.创建用户数据库文件 cd /etc/vsftpddvim vuser.list奇数行为用户名，偶数行为密码.创建文件后需要对用户文件进行加密，并修改权限，然后将明文文件删除，之后创建一个用来虚拟用户登录后映射本地用户的用户。 db_load -T -t hash -f vuser.list vuser.dbchmod 600 vuser.dbrm -f vuser.listuseradd -d /test -s /sbin/nologin2.创建支持虚拟用户的PAM文件新建并编辑/etc/pam.d/vsftpd.vu文件，写下创建的数据库文件的路径auth required pam_userdb.so db=/etc/vsftpd/vuseraccount required pam_userdb.so db=/etc/vsftpd/vuser 3.修改vsftpd.conf配置文件 参数作用anonymous_enable=NO禁止匿名开放模式local_enable=YES允许本地用户模式guest_enable=YES开启虚拟用户模式guest_username=test指定虚拟用户账户pam_service_name=vsftpd.vu指定PAM文件allow_writeable_chroot=YES允许对禁锢的FTP根目录执行写入操作，而且不拒绝用户的登录请求 4.创建虚拟用户权限文件如需要为每个虚拟用户匹配不同的权限，则需要为每个虚拟用户创建权限文件 mkdir user_dir #创建放置权限的文件夹cd user_dirtouch lemon在以虚拟用户名创建的文件中，写入如下参数 anon_upload_enable=YESanon_mkdir_write_enable=YESanon_other_write_enable=YES然后在vsftpd.conf配置文件中追加虚拟用户权限文件夹的路径 user_config_dir=/etc/vsftpd/user_dir之后重启vsftpd服务，至此配置过程完成,如发现服务未启动，无法打开，登录等问题，请检查相关配置文件，查看防火墙配置（ftp服务主动和被动模式防火墙配置不同需注意），SElinux的配置是否正常。

引言Alice学生管理系统昨日正式上线测试，上线遇到的问题不少，但最后都完美解决了。 特此分享，一起爬坑。 项目优化登录页美化原来的登录页采用的是黑背景，经过大家的充分讨论，我们需要换一个登录页，黑背景看着压抑。 然后就在晨澍和潘佳琦的帮助下开始找各种登录的模板，发现都特别丑，后来发现当前系统的登录风格和微信的登录风格很像，顺手就抄过来了，感觉效果还不错。 上线问题打包问题前台ng build --prod之后，发现样式不一致。 期待： 实际结果： 查看元素发现是Bootstrap的样式在打包之后没有了。 后来发现：黄庭祥在style.less中引用了一个在线的Bootstrap，打包肯定打不进去啊。 引用的所有包，都不能引在线的，需要使用npm安装。npm install之后的包才能被打包进去。 远程文件拷贝本地打完包，需要将文件上传到服务器，查了一下，需要使用scp命令。 scp：secure copy，安全拷贝，将文件加密传输，安全的远程文件拷贝命令。 scp -r /Users/panjie/github/yunzhiclub/alice/web/webApp/dist/webApp root@xxx.xxx.xxx.xxx:/root/将本地打包的webApp目录上传到服务器的/root目录下。 -r代表目录，xxx.xxx.xxx.xxx请替换成相应的服务器IP地址。 nginx 403前台上线，浏览器端访问服务器却得到了403，查看相关日志后发现是nginx访问文件时遭到了拒绝。 在nginx的配置文件中，有一行配置用户的。 原配置是user nginx;，所以启动时nginx进程的用户是nginx，但是webApp文件的用户所有者是root，所以就403了。 解决方案是把用户配置改成root(有权限的用户)，然后重新加载配置文件即可。 刷新404问题当用户访问127.0.0.1:8100时，根据路由的重定向，''重定向为'setup'登录界面。 但是用户刷新或直接访问127.0.0.1:8100/setup时，报404错误。 猜想，nginx转发出现了问题，应该是/转给了Angular，但是把/setup当成了文件夹。 这个只是我的猜测，如果您有什么意见，欢迎在评论区中指出我的错误，感激不尽。 华软就没有该类问题，对比两个项目，发现华软中默认配置了hash路由。 hash路由特意去官网学习了一下hash路由，感觉应该能给大家讲明白。 两个路由： 127.0.0.1:8100/setup127.0.0.1:8100/#/setup普通的路由是不带#的，hash路由是带#的。 #号，我们是不是在哪里见过？大家还记得Spring的官方文档吗？ 用a标签实现页面内跳转。hash路由与之类似。 #之后的路由变化不会被发送给服务器，也就是说：127.0.0.1:8100/setup，后台nginx获取到的路径是/setup，而使用hash路由，对于路由127.0.0.1:8100/#/setup，后台获取到的路径就是/。 注入hash路由策略，即可启用hash路由。 再访问，后台获取到的就是/，然后把angular应用返回回来，然后angular应用再去处理#之后的路由，不会出现404。 以上的论述，是我结合官方文档和我的经验得出的解决，如果有不正确之处，欢迎您批评指正。 不足当时忙着上线，ng alain中默认也启用了hash路由，就以为hash路由是正统的解决方案。 但是今天看官方文档，却看到了这样的描述： 几乎所有的Angular项目都会使用默认的HTML 5风格。它生成的URL更易于被用户理解，它也为将来做服务端渲染预留了空间。 在服务器端渲染指定的页面，是一项可以在该应用首次加载时大幅提升响应速度的技术。那些原本需要十秒甚至更长时间加载的应用，可以预先在服务端渲染好，并在少于一秒的时间内完整呈现在用户的设备上。 默认的路由(不带#)的，支持服务器端渲染，而hash路由则不支持。除非你有强烈的理由不得不使用hash路由，否则就应该坚决使用默认的HTML 5路由风格。 hash路由不推荐，不支持SSR。另外，我觉得应该是当前nginx的转发配置写得不好，以后再研究研究。 总结对技术怀着一颗敬畏之心，努力地寻找着最佳实践。

Java获取当前进程ID以及所有Java进程的进程ID 首先是获取当前Java运行的Java进程ID，这个是网上常见的，也就是Java程序自身将进程ID打印出来：package com.test;import java.lang.management.ManagementFactory;import java.lang.management.RuntimeMXBean;public class Target { public static void main(String[] args) throws InterruptedException { System.out.println(getProcessID()); while(true) { Thread.sleep(10000); } } public static final int getProcessID() { RuntimeMXBean runtimeMXBean = ManagementFactory.getRuntimeMXBean(); System.out.println(runtimeMXBean.getName()); return Integer.valueOf(runtimeMXBean.getName().split("@")[0]) .intValue(); } }ManagementFactory是一个在运行时管理和监控Java VM的工厂类，它能提供很多管理VM的静态接口，比如RuntimeMXBean；RuntimeMXBean是Java虚拟机的运行时管理接口. 获取所有正在运行着的Java进程package com.test;import java.util.HashSet;import java.util.Set;import sun.jvmstat.monitor.MonitoredHost;import sun.jvmstat.monitor.MonitoredVm;import sun.jvmstat.monitor.MonitoredVmUtil;import sun.jvmstat.monitor.VmIdentifier;public class ProcessID { public static void main(String[] args) throws Exception { // 获取监控主机 MonitoredHost local = MonitoredHost.getMonitoredHost("localhost"); // 取得所有在活动的虚拟机集合 Set<?> vmlist = new HashSet<Object>(local.activeVms()); // 遍历集合，输出PID和进程名 for(Object process : vmlist) { MonitoredVm vm = local.getMonitoredVm(new VmIdentifier("//" + process)); // 获取类名 String processname = MonitoredVmUtil.mainClass(vm, true); System.out.println(process + " ------> " + processname); } }}MonitoredHost等类位于${JAVA_HOME}/lib/tools.jar_运行结果： ...

我们在进行URLOS应用开发时，经常会用到一些基础系统镜像，如：ubuntu、CentOS、Debian等，我们可以通过docker pull命令直接拉取官方镜像。 root@ubuntu:~# docker pull ubuntu:18.0418.04: Pulling from library/ubuntu898c46f3b1a1: Already exists63366dfa0a50: Already exists041d4cd74a92: Already exists6e1bee0f8701: Already existsDigest: sha256:017eef0b616011647b269b5c65826e2e2ebddbe5d1f8c1e56b3599fb14fabec8Status: Downloaded newer image for ubuntu:18.04root@master-node:~# docker imagesREPOSITORY TAG IMAGE ID CREATED SIZEubuntu 18.04 94e814e2efa8 6 weeks ago 88.9MBroot@ubuntu:~#以上是从docker官方拉取的ubuntu18.04镜像，我们可以基于此镜像制作相关的应用，比如LNP网站环境、LAP网站环境、Nodejs环境等等。简单理解，就是说几乎所有的docker应用都是在这些镜像上层层打包后得到的，应用的最终体积也许有几百M甚至上G，我们如何为应用瘦身以减少对磁盘的消耗呢？ docker官方为我们打造了Alpine。Alpine 的意思是“高山的”，比如 Alpine plants高山植物，Alpine skiing高山滑雪、the alpine resort阿尔卑斯山胜地，其实Alpine是一个操作系统。 Alpine 操作系统是一个面向安全的轻型 Linux 发行版。目前 Docker 官方已开始推荐使用 Alpine 替代之前的 Ubuntu 做为基础镜像环境。这样会带来多个好处。包括镜像下载速度加快，镜像安全性提高，主机之间的切换更方便，占用更少磁盘空间等。 Alpine的特点： 1、小巧：基于Musl libc和busybox，和busybox一样小巧，最小的Docker镜像只有5MB； 2、安全：面向安全的轻量发行版； 3、简单：提供APK包管理工具，软件的搜索、安装、删除、升级都非常方便。 4、适合容器使用：由于小巧、功能完备，非常适合作为容器的基础镜像。 在制作URLOS应用时，我们可以选择Alpine作为系统基础镜像，这样一来可有效降低应用的大小，方便其他用户下载安装。现在我们开始使用Alpine（如果你的系统中没有安装docker，建议先安装URLOS，因为它自带了docker）。 docker下运行Alpine使用docker pull命令拉取Alpine镜像 root@ubuntu:~# docker pull alpineUsing default tag: latestlatest: Pulling from library/alpinebdf0201b3a05: Pull completeDigest: sha256:28ef97b8686a0b5399129e9b763d5b7e5ff03576aa5580d6f4182a49c5fe1913Status: Downloaded newer image for alpine:latestroot@ubuntu:~#使用docker images命令查看镜像 ...

前言当我们从Windows系统上传文件到Linux/Unix系统上时，有时候会由于文件格式导致可执行文件无法使用。 Windows系统的文件格式为DOS，而Linx/Unix系统的文件格式为UNIX。 而在CentOS系统上有个很方便的工具dos2unix/unix2dos可以解决这个问题。Ubuntu上则可以使用tofrodos/fromdos 简介dos2unix（tofrodos）指令可以将DOS格式文件转换为UNIX格式文件。 而unix2dos（fromdos）指令可以将UNIX格式文件转换为DOS格式文件。 安装CentOS下可以直接使用yum安装：sudo yum -y install dos2unix（同时安装了dos2unix/unix2dos）Ubuntu可以使用apt安装：sudo apt-get install tofrodos（同时安装了tofrodos/fromdos）基本使用dos2unix/unix2dos只需要直接执行：dos2unix file就可以将DOS格式的文件转成UNIX格式的文件tofrodos/fromdos则可以执行：tofrodos file就可以将DOS格式的文件转成UNIX格式的文件

DevOps 全链路下图是我们熟知的软件研发环节，在迭代频率高的研发组织里，一天可能要经历多次如下循环。对于用户群体庞大或者正在经历大幅业务扩张的企业研发组织，除了重点关注应用的快速上线之外，如何保障应用的高可靠、高可用也成为焦点，即服务上线要快，运行要好。如何让开发更简单，运行更高效，接下来我们从两个角度来探讨这个问题：组织方式研发工具关于运维人员的组织方式一种方式是组建专门的运维团队，一个运维团队往往会承接多个开发团队的协作。除了 DBA 这类针对某个中间件的运维之外，这种模式的弊端在于不少运维工程师深陷于环境配置、日志收集、业务恢复、现象记录等琐碎事情当中，没有时间阅读项目源码以及提升能力，对较为深入的业务问题分析困难，开发团队又往往无暇分身，运维容易陷入被动的境地。另一种方式，开发人同时负责各自模块的开发与运维。好处自然是由于开发人员熟悉本模块源码，定位问题的效率要高出不少。同时开发者可以直接得到下游用户使用反馈，将其融入到研发当中去。坏处在于，让开发人员陷入到频繁的用户问题定位之后，难以保证代码开发的时间。近年来，国内也兴起了 SRE 这种高级运维职业，特别是在云计算行业，SRE 的职业要求非常高，需要精通诸如网络、编程、算法、数据结构、操作系统、安全等知识与技能。当云平台出现网络故障、系统故障等问题，这对云租户/用户有时甚至是致命的，所以不少 SRE 是由高级别开发人员转型而来。在 Google SRE 的服务可靠性层级当中，SRE 通过产品、开发、容量规划、测试、根因分析、事件响应、监控七个层次的实践来确保应用服务的健康状态。从这个层级当中我们可以看出 Google 提倡运维要积极控制服务发展的方向，而不仅仅在事故发生后反应性地灭火。目前来看，SRE 这种精英式的运维在国内还有待探索与实践。粗暴地将开发运维拆开，或者将开发运维简单合并，都不是特别合适的一种方式。从笔者的研发经验看，一种方式可供大家思考与讨论——根据业务实际情况做分工：比如由团队内的开发者轮流负责整个项目运维。由于各个开发者对项目公共代码都需要熟悉，在理解其它模块代码也相对快速，这种方式基本能消灭大部分的问题，剩下的一小部分可以和指定模块的负责人结对定位。除此之外，为“每个服务团队分派运维联络人”，“邀请运维工程师参加开发团队的会议”都是能够加强运维与开发之间协作的措施。关于工具的使用除了恰当的人员组织方式之外，合适的工具也能给研发团队注入能力。在配置研发环境时，研发组织可以选择通过开源工具自建代码管理和持续构建环境。这种方式的缺点在于需要有专门的 CI 团队来维护持续构建环境，一旦环境被破坏，开发的脚步就会停滞。并且由于各个开源工具数据未打通，开发人员要在多个工具之间切换使用。另外一种方式就可以通过现有的软件研发管理系统，例如 CODING 研发管理系统，来实现一站式的研发流程管理，无需自建、维护众多的研发工具与研发环境，支持在浏览器中完成全套软件开发流程，真正做到了 Coding Anytime Anywhere。当开发人员通过 CODING 研发管理系统快速开发并部署好应用后，下一步就要让应用在运维工具的辅助监控下可靠运行（并不是所有应用都需要运维工具，需对症下药）。研发组织可以选择自己开发运维工具，也可以选择现有的运维工具。目前的运维工具逐渐地朝以应用为中心发展，因为应用是直接向用户提供业务能力的，无论是开发还是运维，都是被业务价值驱动的。主流的运维工具主要涵盖基础设施层监控、应用层面监控、业务层面的分析与监控。接下来我们看看现有的运维工具一般会提供哪些具体能力：基础设施环境的监控：对服务器整体的 CPU、内存、磁盘、文件系统、网络等资源占用情况进行上报。应用性能监控：针对应用使用的中间件，例如持久化数据库、缓存数据库、消息中间件等访问效率进行监控；以及对应用本身请求响应速度进行监控，包括延迟、吞吐量等等。应用调用链路追踪：在分布式系统下，一个请求往往需要经过多个进程处理完毕。当出现用户请求调用失败或者出错时，运维平台支持整个调用链路的分析与故障环节定位。日志数据采集与分析：日志的采集主要是为了辅助应用调用链路分析以及性能监控，运维人员无需进入后台去大量翻找日志。故障自动恢复灵活的告警可视化面板展示监控与告警信息国外热度较高的运维工具包括 ZIPKIN（分布式追踪），pinpoint（分布式追踪），logstash（数据收集）等等。目前国内各大云厂商也基本都提供了应用运维平台，包括腾讯蓝鲸、阿里 ARMS、华为 APM 等。以下是这几个运维平台能力的简要对比：目前大部分的运维平台主要通过 Agent 和探针的方式去采集应用的指标信息，汇总处理后反应在可视化界面上。除上述的工具和平台之外，AIOps 也逐渐成为未来的一个趋势，AIOps 通过 AI 技术的运用来进行智能业务故障诊断，同时自动恢复应用故障，企图让研发组织彻底告别人肉运维时代，笔者也万分期待这天的到来。运维人员不用担心因 AIOps 失业，工具和平台只是提升运维效率，不会取代运维。在运维阶段发现缺陷后，开发人员可在 CODING 中处理对应的缺陷，记录下每个缺陷的类型、优先级、模块、描述、处理人等信息。软件缺陷是不可避免的，但只有通过对缺陷进行管理和复盘才能知道缺陷产生的原因（人为因素 / 环境因素 / 工具问题等），从而改进，避免类似缺陷的重复。对缺陷的管理也有助于管理人员对软件质量的正确评估。缺陷处理人通过 CODING 实现缺陷的快速修复和部署，可大大缩短故障恢复时间，减少因缺陷产生的业务损失。在 DevOps 理念的指导下，笔者建议开发人员在开发业务代码时，除了功能之外，也应当思考如何开发可运维的代码，通过适当的日志、错误码、异常等措施来提升运维效率；运维人员也需逐步提升能力，从传统的繁杂运维当中转型，走上敏捷自动化的运维之路。写在最后我们可以看到随着 DevOps 工具链自动化显著提升，DevOps 的门槛变得更加地低。拥抱自动化的结果是研发过程会变得越来越安静，顶尖的开源项目里的 committers 在日常仅仅是通过邮件和 issue 将事情说清楚，没有热火朝天、冗长拖沓的会议；也没有花花绿绿，色彩斑斓的工作表格。但这些都是建立在 DevOps 良好实践的基础之上。我们相信在践行 DevOps 的道路上，未来软件的开发会更简单，运行也会更加高效。参考：https://www.collab.nethttps://landing.google.com/sr…吉恩·金（Gene Kim）；耶斯·亨布尔（Jez Humble）；帕特里克·德布瓦（Patrick Debois）；约翰·威尔斯（John Willis）.《DevOps 实践指南》

DevOps是如何出现的？前因后果更多物联网高并发编程知识请移步：https://www.yuque.com/shizhiy…软件开发的演变多年来，DevOps从现有的软件开发策略/方法发展而来，以响应业务需求。让我们简要地看一下这些模型是如何演变的，以及它们最适合的场景。缓慢而繁琐的瀑布模型演变成敏捷，开发团队在短时间内完成软件开发，持续时间甚至不超过两周。如此短的发布周期帮助开发团队处理客户反馈，并将其与bug修复一起合并到下一个版本中。 虽然这种敏捷的SCRUM方法为开发带来了敏捷性，但它在运维方面却失去了敏捷实践的速度。开发人员和运维工程师之间缺乏协作仍然会减慢开发过程和发布。DevOps方法就是基于对更好的协作和更快的交付的需求而产生的。DevOps允许用较少复杂问题的持续软件交付来修复和更快地解决问题。讲故事为了能够更好的理解什么是DevOps，我们很有必要对当时还只有程序员(此前还没有派生出开发者，前台工程师，后台工程师之类)这个称号存在的历史进行一下回顾。如编程之道中所言：老一辈的程序员是神秘且深奥的。我们没法揣摩他们的想法，我们所能做的只是描述一下他们的表象。清醒的像一只游过水面的狐狸警惕的像一位战场上的将军友善的像一位招待客人的女主人单纯的像一块未经雕琢的木头深邃的像一潭幽深洞穴中漆黑的池水i am you father程序员开发了机器语言，机器语言又产生了汇编语言，汇编语言产生了编译器，如今的语言已经多不胜数。每一种语言都有其各自的谦卑用途。每一种语言都表达出软件的阴和阳。每一种语言都在此道之中有其一席之地。遥想当年，软件程序员的大部分办公司那时还被称作实验室，程序员那时还叫做科学家。为了开发出一套优秀的软件，程序员们必须深入了解他们需要的应用相关的所有问题。他们必须清楚知道这个软件应用在什么场合，这个软件是必须在什么系统上运行。本质上说，程序员对所要开发的软件的所有环节都有透彻的了解，从规格说明书编写、到软件开发、到测试、到部署、再到技术支持。过了不久，人类(客户)贪婪的特性就开始表现出来，他们开始不断的进行更多的索求。更快的速度，更多的功能，更多的用户，更多的所有所有。作为一类谦虚、谦卑、且平静的生物，我们的老一辈程序员们将很难在这种爆发性的过度的需求索取中幸存。最好的取胜办法就是往不同的方向进化成不同的新物种。很快，程序员这个称号就开始绝迹于江湖，而那些叫做开发者、软件工程师、网络管理员、数据库开发者、网页开发者、系统架构师、测试工程师等等更多的新物种就开始诞生。快速进化和快速适应外界的挑战成为了他们的DNA的一部分。这些新的种族可以在几个星期内就完成进化。网页开发者很快就能进化成后台开发者，前台开发者，PHP开发者，Ruby开发者，Angular开发者…多得让人侧目。很快他们就都忘却了他们都是起源于程序员这个共同的祖先的事实，忘却了曾经有过这么一个单纯且平静的，想要让这个世界变得更好的科学家。然后他们开始不断的剑拔弩张，都声称自己才是“程序员”的纯血统继承人。随着时间的转移，各门各派开始独占山头，很少进行交流互动，只有在迫不得已的时刻才会进行沟通。他们开始不再为同源的遥远的同宗兄弟们的成功而欢呼雀跃，甚至再也不会时把的遥寄张明信片进行嘘寒问暖。但是在深夜仰望星空的时候，他们还是会发现他们的心底深处的程序员基因还是会不停的闪烁着，期盼着这闪烁的火花能照亮整个银河系并带来和平。瀑布开放流程在这场自私且以自我为中心的欲征服世界的赛跑旅程里，程序员的子孙们早把他们真正的工作目标置之脑后-为客户解决问题。面对一拖再拖的项目交付日期，昂贵的开发代价，甚至最终失败的项目，客户们开始对这种情况深恶痛绝。偶尔，也会有一个闪亮的明星站出来，灵机一动的提供一种办法来尝试结束这种混乱并带来和平。所以瀑布开发流程就应运而生了。这是一个非常了不起的创意，因为它利用了不同团队的开发者们只在必须的时候才进行沟通的这个事实。当一个团队完成了他们的工作的时候，它就会和下游的团队进行交流并把任务进行往下传，如此一级接一级的传递下去，永不回首敏捷开发这种方式在一段时间内发挥了效用，但很快，一如既往，贪婪的人们(客户)又开始提出更多的诉求。他们希望能够更多地参加到整个软件的开发流程中来，不时的提出他们的建议，甚至在很晚的时候还提出改需求这种丧心病狂的事情来。结果就是如大家有目共睹的事实一样，软件项目非常容易失败这个说法已经作为一个行业标准被人们所接受。数据表明超过50%的项目最终都是以失败告终的。更可悲的是，在当时看来，人们对这种情况是束手无策。值得庆幸的是，每一个时代总会有那么几个思想开放的英雄如漆黑中的萤火虫般冒出来。他们知道这些不同团队的开发者们必须要找到一个可以协同工作、进行交流、并且能够弹性的向客户保证对方将会拿到最优的解决方案的方式。这种尝试最早可以追溯到1957年，伟大的约翰·冯·诺依曼和同行们的努力。但是我们最终却是等到2001年才收获到革命的果实，当时行业的十多个精英创造出了如今闻名世界的“敏捷宣言”。敏捷宣言基于以下十二条原则：我们的首要任务是通过尽早地、持续地交付可评价的软件来使客户满意。乐于接受需求变更，即使是在开发后期也应如此。敏捷过程能够驾驭变化，从而为客户赢得竞争优势。频繁交付可使用的软件，交付间隔越短越好，可以从几个星期到几个月。在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。围绕那些有推动力的人们来构建项目。给予他们所需的环境和支持，并且信任他们能够把工作完成好。与开发团队以及在开发团队内部最快速、有效的传递信息的方法就是，面对面的交谈。可使用的软件是进度的主要衡量指标。敏捷过程提倡可持续发展。出资人、开发人员以及使用者应该总是共同维持稳定的开发速度。为了增强敏捷能力，应持续关注技术上的杰出成果和良好的设计。简洁——最大化不必要工作量的艺术——是至关重要的。最好的架构、需求和设计都源自自我组织的团队。团队应该定期反思如何能变得更有战斗力，然后相应地转变并调整其行为。敏捷宣言是为银河系带来和平以及维护各自的平衡所迈出的很重要的第一步。在很长的时间里，相比此前基于流程和机械化的方式，这是第一次基于文化和“人性”来将不同的关键项目关系人连接在一起的方式。人们开始互相交流，进行基本的碰头会议，并开始不断的交流意见和看法。他们开始意识到他们是有着很多比想象中还多的共同点的，客户也开始成为他们之中的一员，而不再是像以往一样只是往项目砸钱然后开始求神拜佛祈求一切顺利如愿。精益软件开发尽管前面还是有不少的障碍需要克服，但是未来已经光明了许多。敏捷意味着开放和拥抱(需求)改变。但是，如果改变过多的话，人们就很难专注到最终的目标和交付上来。此时精益软件开发就开始破土而出了。因为对精益软件开发的着迷以及为了达成放逐和驱赶风险的目的，一些程序员的子孙们就开始探首窗外，开始向软件之外的行业进行取经。他们从一家主要的汽车生产商身上找到了救赎。丰田生产系统在精益上面的成就是不可思议的，同时它们的精益生产的经验也是很容易应用到软件开发上来的。精益有以下7个原则：杜绝浪费内建质量创建知识(放大学习)延迟决策(尽量延迟决定)快速交付尊重人员(团队授权)全局优化将这些放到敏捷上去的话，精益原则就能让人们在从精神上关注做正确的事情，同时还能够让整个开发流程拥有足够的弹性。DevOps一旦敏捷和精益软件开发被软件开发团队采纳，那么下一步就是把这一套原则应用到IT团队上来。把IT也纳入到整体战略上，然后我们就来到了DevOps跟前了！进入DevOps – 高速公路的三条车道老一派的软件开发团队成员会包含业务分析员，系统架构师，前端开发者，后端开发者，测试员，等等。优化如敏捷和精益原则等的软件开发流程的关注点就在这些地方。比如，软件一旦达到”可以生产“的程度，就会发到系统工程师、发布工程师、DBA、网络工程师，安全专家这些“运维人员”的手上。这里该如何将横在Dev(开发)和Ops(运维)之间的鸿沟给填平，这就是DevOps的主要关注点了。DevOps是在整个IT价值流中实施精益原则的结果。IT价值流将开发延伸至生产，将由程序员这个遥远的祖宗所繁衍的所有子孙给联合在一起。这是来自Gene Kim的对DevOps的最好的解析。你不应该重新招聘DevOps工程师，且DevOps也不应该是一个IT的新部门。DevOps是一种文化，一种理念，且是和IT糅合成一整体的。世间没有任何工具可以把你的IT变成一个DevOps组织，也没有任何自动化方式可以指引你该如何为你的客户提供最大化的效益。DevOps通常作为下面这三个方式而为人所熟知，而在我眼里我是把它们看成是一条高速公路上的三条车道。你从第一条车道开始，然后加速进入到第二条车道，最终在第三车道上高速行驶。车道1 – 系统级别的整体效率考量是最主要的关注点，这超过对系统中任何一个单独个体元素的考虑车道2 – 确保能提供持续不断的反馈循环，且这些反馈不被忽视。车道3 – 持续的学习和吸取经验，不停的进步，快速的失败。车道1 – 获取速度要采纳DevOps的原则，理解整个运作系统的重要性并对工作事项进行合适的优先级排序是组织首先要学的事情。在整个价值流中不能允许任何人产生瓶颈并降低整个工作流程。确保工作流程的不可中断是身处流程中的所有成员的终极目标。无论一个成员或者团队的角色是什么，他们都必须力图对整个系统进行深入的理解。这种思维方式对质量会有着直接的影响，因为缺陷永远不会被下放到“下游“中，这样做的话将会导致瓶颈的产生。确保整个工作流程不会被瓶颈堵塞住还不够。一个高产的组织应该时常考虑该如何提升整个工作流程。有很多方法论可以做到这一点，你不妨去看下“约束理论”，“六西格玛”，精益，或者丰田生产系统。DevOps原则不关心你身处哪个团队，你是否是系统架构师，DBA，QA，或者是网络管理员。相同的规则覆盖所有的成员，每个成员都应该遵循两个简单的原则：保持系统运作流程不可中断随时提升和优化工作流程车道2 – 换挡加速不可中断的系统流程是定向的，且预期是从开发流向运维。在一个理想的世界中，这就意味着快速的开发出高质量的软件，部署，并为客户提供价值。但是，DevOps并非乌托邦式的理想国。如果单向的交付方式是可行的话，我们的瀑布模式早就能胜任了。评估可交付产品和整个流程中的交流对确保质量是至关重要的。这里首个必须实现的”面向上游”的交流通道是从Ops到Dev。我们独自意淫是件非常容易的事情，但是获取别人的反馈和提供反馈给别人才是探究事实真相的正确方法。下游的每一步(反馈)都必须紧跟着有一个上游的确定。你如何建立反馈循环机制并不重要。你可以邀请开发人员加入技术支持团队的会议，或者将网络管理员放到Sprint计划会议中去。一旦你的反馈机制就绪，反馈能够被接收并被处理，你就已经可以说是走到了DevOps高速车道上来了。车道3 – 飞速前进DevOps这条快速车道并不适合意志脆弱的人。为了进入这条车道，你的组织必须要足够的成熟。这里充满了冒险和对失败教训的学习，不断的尝试，并认同屡败屡战和不断的实践是走向成功这条康庄大道的前提条件。在这里你应该会经常听到”套路“这个词，这是有原因的。不断的训练和重复所以能培养出大师，是因为其让复杂的动作常规化。但是在你要将这些复杂的动作连接起来之前，你很有必要先去掌握好每一个单独步骤。“适合大师的动作并不适合新手，脱胎换骨之前你必须先要明白道的真谛。“DevOps的第三个方式/快速车道包括每天分配时间来持续的进行试验，时常的奖励敢于冒险的团队，并将缺陷特意引入到运作系统上来以增加系统的抗击打能力。为了确保你的组织能够消化好这些方法，你必须在每个团队之间建立好频繁的反馈循环，同时需要确保所有的瓶颈都能够及时的被清理掉，并确保整个系统的运作流程是不可中断的。实施好这些措施可以让你的组织时刻保持警惕，并能够快速且高效的应对挑战。DevOps清单下面是一张你可以用来检验你的组织对DevOps的应用情况的清单。开发团队和运维团队之间没有障碍。两者皆是DevOps统一流程的一部分。从一个团队流到另一个团队的工作都能够得到高质量的验证工作没有堆积，所有的瓶颈都已经被处理好。开发团队没有占用运维团队的时间，因为部署和维护都是处于同一个时间盒里面的。开发团队不会在周五下午5点后把代码交付进行部署，剩下运维团队周末加班加点来给他们擦屁股开发环境标准化，运维人员可以很容易將之扩展并进行部署开发团队可以找到合适的方式交付新版本，且运维团队可以轻易的进行部署。每个团队之间的通信线路都很明确所有的团队成员都有时间去为改善系统进行试验和实践常规性的引入(或者模拟)缺陷到系统中来并得到处理。每次学习到的经验都应该文档化下来并分享给相关人员。事故处理成为日常工作的一部分，且处理方式是已知的总结使用现代化的DevOps工具，如Chef、Docker、Ansible、Packer、Troposphere、Consul、Jenkins、SonarQube、AWS等，并不代表你就在正确的应用DevOps的原则。DevOps是一种思维方式。我们所有人都是该系统流程的一部分，我们一起分享共同的时光和交付价值。每个参加到这个软件交付流程上来的成员都能够加速或减缓整个系统的运作速度。系统出现的一个缺陷，以及错误配置的团队之间的“防火墙”，都可能会使得整个系统瘫痪，所有的人都是DevOps的一部分，一旦你的组织明白了这一点，能够帮你管理好这些的工具和技术栈就自然而然的会出现在你眼前了。

Envoy是一个composer扩展包，它的本质作用是代替你登录远程的目标服务器（下称目标机）并执行一系列命令，它的执行环境要有事先装有php与composer，但它不仅仅能在php项目里起作用，原因是前面提到的它的本质是帮你执行命令，而这命令不只针对php的命令。因此你不仅可以把它当作部署项目的工具，甚至可以是对目标机的简单管理工具。下面从本地机对目标机的登录到envoy的安装使用来分步介绍它。实现本地机与目标机的ssh密钥登录假定目标服务器是sorgo@192.168.8.8#如果本地机的用户还没rsa密钥的那先生成ssh-keygen -t rsa -C “your_email@example.com”#发送密钥到目标机，并进行密码验证ssh-copy-id sorgo@192.168.8.8#测试是否能直接ssh登录而不再要求输入密码ssh sorgo@192.168.8.8安装和使用#全局安装composer global require laravel/envoy#一键生成envoy执行文件模板：Envoy.blade.phpenvoy init sorgo@192.168.8.8修改Envoy.blade.php文件{{– 这是blade文件里的注释 –}}{{– web是标识这台服务器的名字 –}}@servers([‘web’ => ‘jeffio@116.85.48.221’]){{– deploy是给这个任务起的名字 –}}@task(‘deploy’) cd /www/wwwroot/sifou.com git pull origin master composer install@endtask执行任务，命令格式是envoy run 任务名envoy run deploy以上即可一键完成：进入指定目录git拉取更新安装composer包这样一个简单的部署就完成了，极大降低了维护的操作成本。参考更多写操作请参考收下文档Envoy详细文档

java进程管理程序 命名:jmanager主要功能：保存当前主机所有Java进程信息，停止Java进程，启动Java进程解决的问题：公司目前测试环境只有几台虚拟机，没有进行容器化管理，系统采用分布式架构，需要部署的程序很多。一旦虚拟机重启或者故障就要适用Jenkins重启打包部署非常耗时和麻烦，遂编写该脚本用于定时抓取Java进程启动信息，一旦出现故障，可以批量停止Java进程或者批量启动Java进程。适用环境： linux系统并已安装python3，可以执行jps命令如何安装：git clone https://github.com/mudiyouyou/jmanager.git安装如下python库pip3 install jsonpip3 install psutil如何因为网络限制建议使用如下命令pip3 install json -i http://mirrors.aliyun.com/pypi/simple/ –trusted-host mirrors.aliyun.compip3 install psutil -i http://mirrors.aliyun.com/pypi/simple/ –trusted-host mirrors.aliyun.com如何操作：python3 main.py log 解释：记录当前所有java进程信息，产生以当前日志命名的进程数据文件python3 main.py stop xxxx.json 解释：关闭所有Java进程 xxxx.json 为第一步产生的数据文件python3 main.py start xxxx.json 解释：启动所有Java进程 xxxx.json 为第一步产生的数据文件该脚本适用于所有java程序，可以安装在其他环境，但该脚本不负责程序启动或者停止顺序

本文由云+社区发表作者：邹立巍版权声明：本文章内容在非商业使用前提下可无需授权任意转载、发布。转载、发布请务必注明作者和其微博、微信公众号地址，以便读者询问问题和甄误反馈，共同进步。微博ID：orroz微信公众号：Linux系统技术前言管道是UNIX环境中历史最悠久的进程间通信方式。本文主要说明在Linux环境上如何使用管道。阅读本文可以帮你解决以下问题：什么是管道和为什么要有管道？管道怎么分类？管道的实现是什么样的？管道有多大？管道的大小是不是可以调整？如何调整？什么是管道？管道，英文为pipe。这是一个我们在学习Linux命令行的时候就会引入的一个很重要的概念。它的发明人是道格拉斯.麦克罗伊，这位也是UNIX上早期shell的发明人。他在发明了shell之后，发现系统操作执行命令的时候，经常有需求要将一个程序的输出交给另一个程序进行处理，这种操作可以使用输入输出重定向加文件搞定，比如：[zorro@zorro-pc pipe]$ ls -l /etc/ > etc.txt[zorro@zorro-pc pipe]$ wc -l etc.txt 183 etc.txt但是这样未免显得太麻烦了。所以，管道的概念应运而生。目前在任何一个shell中，都可以使用“|”连接两个命令，shell会将前后两个进程的输入输出用一个管道相连，以便达到进程间通信的目的：[zorro@zorro-pc pipe]$ ls -l /etc/ | wc -l183对比以上两种方法，我们也可以理解为，管道本质上就是一个文件，前面的进程以写方式打开文件，后面的进程以读方式打开。这样前面写完后面读，于是就实现了通信。实际上管道的设计也是遵循UNIX的“一切皆文件”设计原则的，它本质上就是一个文件。Linux系统直接把管道实现成了一种文件系统，借助VFS给应用程序提供操作接口。虽然实现形态上是文件，但是管道本身并不占用磁盘或者其他外部存储的空间。在Linux的实现上，它占用的是内存空间。所以，Linux上的管道就是一个操作方式为文件的内存缓冲区。管道的分类和使用Linux上的管道分两种类型：匿名管道命名管道这两种管道也叫做有名或无名管道。匿名管道最常见的形态就是我们在shell操作中最常用的”|”。它的特点是只能在父子进程中使用，父进程在产生子进程前必须打开一个管道文件，然后fork产生子进程，这样子进程通过拷贝父进程的进程地址空间获得同一个管道文件的描述符，以达到使用同一个管道通信的目的。此时除了父子进程外，没人知道这个管道文件的描述符，所以通过这个管道中的信息无法传递给其他进程。这保证了传输数据的安全性，当然也降低了管道了通用性，于是系统还提供了命名管道。我们可以使用mkfifo或mknod命令来创建一个命名管道，这跟创建一个文件没有什么区别：[zorro@zorro-pc pipe]$ mkfifo pipe[zorro@zorro-pc pipe]$ ls -l pipe prw-r–r– 1 zorro zorro 0 Jul 14 10:44 pipe可以看到创建出来的文件类型比较特殊，是p类型。表示这是一个管道文件。有了这个管道文件，系统中就有了对一个管道的全局名称，于是任何两个不相关的进程都可以通过这个管道文件进行通信了。比如我们现在让一个进程写这个管道文件：[zorro@zorro-pc pipe]$ echo xxxxxxxxxxxxxx > pipe 此时这个写操作会阻塞，因为管道另一端没有人读。这是内核对管道文件定义的默认行为。此时如果有进程读这个管道，那么这个写操作的阻塞才会解除：[zorro@zorro-pc pipe]$ cat pipe xxxxxxxxxxxxxx大家可以观察到，当我们cat完这个文件之后，另一端的echo命令也返回了。这就是命名管道。Linux系统无论对于命名管道和匿名管道，底层都用的是同一种文件系统的操作行为，这种文件系统叫pipefs。大家可以在/etc/proc/filesystems文件中找到你的系统是不是支持这种文件系统：[zorro@zorro-pc pipe]$ cat /proc/filesystems |grep pipefsnodev pipefs观察完了如何在命令行中使用管道之后，我们再来看看如何在系统编程中使用管道。PIPE我们可以把匿名管道和命名管道分别叫做PIPE和FIFO。这主要因为在系统编程中，创建匿名管道的系统调用是pipe()，而创建命名管道的函数是mkfifo()。使用mknod()系统调用并指定文件类型为为S_IFIFO也可以创建一个FIFO。使用pipe()系统调用可以创建一个匿名管道，这个系统调用的原型为：#include <unistd.h>int pipe(int pipefd[2]);这个方法将会创建出两个文件描述符，可以使用pipefd这个数组来引用这两个描述符进行文件操作。pipefd[0]是读方式打开，作为管道的读描述符。pipefd[1]是写方式打开，作为管道的写描述符。从管道写端写入的数据会被内核缓存直到有人从另一端读取为止。我们来看一下如何在一个进程中使用管道，虽然这个例子并没有什么意义：[zorro@zorro-pc pipe]$ cat pipe.c#include <stdlib.h>#include <stdio.h>#include <unistd.h>#include <string.h>#define STRING “hello world!“int main(){ int pipefd[2]; char buf[BUFSIZ]; if (pipe(pipefd) == -1) { perror(“pipe()”); exit(1); } if (write(pipefd[1], STRING, strlen(STRING)) < 0) { perror(“write()”); exit(1); } if (read(pipefd[0], buf, BUFSIZ) < 0) { perror(“write()”); exit(1); } printf("%s\n”, buf); exit(0);}这个程序创建了一个管道，并且对管道写了一个字符串之后从管道读取，并打印在标准输出上。用一个图来说明这个程序的状态就是这样的：一个进程自己给自己发送消息这当然不叫进程间通信，所以实际情况中我们不会在单个进程中使用管道。进程在pipe创建完管道之后，往往都要fork产生子进程，成为如下图表示的样子：如图中描述，fork产生的子进程会继承父进程对应的文件描述符。利用这个特性，父进程先pipe创建管道之后，子进程也会得到同一个管道的读写文件描述符。从而实现了父子两个进程使用一个管道可以完成半双工通信。此时，父进程可以通过fd[1]给子进程发消息，子进程通过fd[0]读。子进程也可以通过fd[1]给父进程发消息，父进程用fd[0]读。程序实例如下：[zorro@zorro-pc pipe]$ cat pipe_parent_child.c#include <stdlib.h>#include <stdio.h>#include <unistd.h>#include <string.h>#include <sys/types.h>#include <sys/wait.h>#define STRING “hello world!“int main(){ int pipefd[2]; pid_t pid; char buf[BUFSIZ]; if (pipe(pipefd) == -1) { perror(“pipe()”); exit(1); } pid = fork(); if (pid == -1) { perror(“fork()”); exit(1); } if (pid == 0) { /* this is child. / printf(“Child pid is: %d\n”, getpid()); if (read(pipefd[0], buf, BUFSIZ) < 0) { perror(“write()”); exit(1); } printf("%s\n”, buf); bzero(buf, BUFSIZ); snprintf(buf, BUFSIZ, “Message from child: My pid is: %d”, getpid()); if (write(pipefd[1], buf, strlen(buf)) < 0) { perror(“write()”); exit(1); } } else { / this is parent / printf(“Parent pid is: %d\n”, getpid()); snprintf(buf, BUFSIZ, “Message from parent: My pid is: %d”, getpid()); if (write(pipefd[1], buf, strlen(buf)) < 0) { perror(“write()”); exit(1); } sleep(1); bzero(buf, BUFSIZ); if (read(pipefd[0], buf, BUFSIZ) < 0) { perror(“write()”); exit(1); } printf("%s\n”, buf); wait(NULL); } exit(0);}父进程先给子进程发一个消息，子进程接收到之后打印消息，之后再给父进程发消息，父进程再打印从子进程接收到的消息。程序执行效果：[zorro@zorro-pc pipe]$ ./pipe_parent_child Parent pid is: 8309Child pid is: 8310Message from parent: My pid is: 8309Message from child: My pid is: 8310从这个程序中我们可以看到，管道实际上可以实现一个半双工通信的机制。使用同一个管道的父子进程可以分时给对方发送消息。我们也可以看到对管道读写的一些特点，即：在管道中没有数据的情况下，对管道的读操作会阻塞，直到管道内有数据为止。当一次写的数据量不超过管道容量的时候，对管道的写操作一般不会阻塞，直接将要写的数据写入管道缓冲区即可。当然写操作也不会再所有情况下都不阻塞。这里我们要先来了解一下管道的内核实现。上文说过，管道实际上就是内核控制的一个内存缓冲区，既然是缓冲区，就有容量上限。我们把管道一次最多可以缓存的数据量大小叫做PIPESIZE。内核在处理管道数据的时候，底层也要调用类似read和write这样的方法进行数据拷贝，这种内核操作每次可以操作的数据量也是有限的，一般的操作长度为一个page，即默认为4k字节。我们把每次可以操作的数据量长度叫做PIPEBUF。POSIX标准中，对PIPEBUF有长度限制，要求其最小长度不得低于512字节。PIPEBUF的作用是，内核在处理管道的时候，如果每次读写操作的数据长度不大于PIPEBUF时，保证其操作是原子的。而PIPESIZE的影响是，大于其长度的写操作会被阻塞，直到当前管道中的数据被读取为止。在Linux 2.6.11之前，PIPESIZE和PIPEBUF实际上是一样的。在这之后，Linux重新实现了一个管道缓存，并将它与写操作的PIPEBUF实现成了不同的概念，形成了一个默认长度为65536字节的PIPESIZE，而PIPEBUF只影响相关读写操作的原子性。从Linux 2.6.35之后，在fcntl系统调用方法中实现了F_GETPIPE_SZ和F_SETPIPE_SZ操作，来分别查看当前管道容量和设置管道容量。管道容量容量上限可以在/proc/sys/fs/pipe-max-size进行设置。#define BUFSIZE 65536……ret = fcntl(pipefd[1], F_GETPIPE_SZ);if (ret < 0) { perror(“fcntl()”); exit(1);}printf(“PIPESIZE: %d\n”, ret);ret = fcntl(pipefd[1], F_SETPIPE_SZ, BUFSIZE);if (ret < 0) { perror(“fcntl()”); exit(1);}……PIPEBUF和PIPESIZE对管道操作的影响会因为管道描述符是否被设置为非阻塞方式而有行为变化，n为要写入的数据量时具体为：O_NONBLOCK关闭，n <= PIPE_BUF：n个字节的写入操作是原子操作，write系统调用可能会因为管道容量(PIPESIZE)没有足够的空间存放n字节长度而阻塞。O_NONBLOCK打开，n <= PIPE_BUF：如果有足够的空间存放n字节长度，write调用会立即返回成功，并且对数据进行写操作。空间不够则立即报错返回，并且errno被设置为EAGAIN。O_NONBLOCK关闭，n > PIPE_BUF：对n字节的写入操作不保证是原子的，就是说这次写入操作的数据可能会跟其他进程写这个管道的数据进行交叉。当管道容量长度低于要写的数据长度的时候write操作会被阻塞。O_NONBLOCK打开，n > PIPE_BUF：如果管道空间已满。write调用报错返回并且errno被设置为EAGAIN。如果没满，则可能会写入从1到n个字节长度，这取决于当前管道的剩余空间长度，并且这些数据可能跟别的进程的数据有交叉。以上是在使用半双工管道的时候要注意的事情，因为在这种情况下，管道的两端都可能有多个进程进行读写处理。如果再加上线程，则事情可能变得更复杂。实际上，我们在使用管道的时候，并不推荐这样来用。管道推荐的使用方法是其单工模式：即只有两个进程通信，一个进程只写管道，另一个进程只读管道。实现为：[zorro@zorro-pc pipe]$ cat pipe_parent_child2.c#include <stdlib.h>#include <stdio.h>#include <unistd.h>#include <string.h>#include <sys/types.h>#include <sys/wait.h>#define STRING “hello world!“int main(){ int pipefd[2]; pid_t pid; char buf[BUFSIZ]; if (pipe(pipefd) == -1) { perror(“pipe()”); exit(1); } pid = fork(); if (pid == -1) { perror(“fork()”); exit(1); } if (pid == 0) { / this is child. / close(pipefd[1]); printf(“Child pid is: %d\n”, getpid()); if (read(pipefd[0], buf, BUFSIZ) < 0) { perror(“write()”); exit(1); } printf("%s\n”, buf); } else { / this is parent / close(pipefd[0]); printf(“Parent pid is: %d\n”, getpid()); snprintf(buf, BUFSIZ, “Message from parent: My pid is: %d”, getpid()); if (write(pipefd[1], buf, strlen(buf)) < 0) { perror(“write()”); exit(1); } wait(NULL); } exit(0);}这个程序实际上比上一个要简单，父进程关闭管道的读端，只写管道。子进程关闭管道的写端，只读管道。整个管道的打开效果最后成为下图所示：此时两个进程就只用管道实现了一个单工通信，并且这种状态下不用考虑多个进程同时对管道写产生的数据交叉的问题，这是最经典的管道打开方式，也是我们推荐的管道使用方式。另外，作为一个程序员，即使我们了解了Linux管道的实现，我们的代码也不能依赖其特性，所以处理管道时该越界判断还是要判断，该错误检查还是要检查，这样代码才能更健壮。FIFO命名管道在底层的实现跟匿名管道完全一致，区别只是命名管道会有一个全局可见的文件名以供别人open打开使用。再程序中创建一个命名管道文件的方法有两种，一种是使用mkfifo函数。另一种是使用mknod系统调用，例子如下：[zorro@zorro-pc pipe]$ cat mymkfifo.c#include <stdio.h>#include <sys/types.h>#include <sys/stat.h>#include <stdlib.h>int main(int argc, char argv[]){ if (argc != 2) { fprintf(stderr, “Argument error!\n”); exit(1); }/ if (mkfifo(argv[1], 0600) < 0) { perror(“mkfifo()”); exit(1); }/ if (mknod(argv[1], 0600|S_IFIFO, 0) < 0) { perror(“mknod()”); exit(1); } exit(0);}我们使用第一个参数作为创建的文件路径。创建完之后，其他进程就可以使用open()、read()、write()标准文件操作等方法进行使用了。其余所有的操作跟匿名管道使用类似。需要注意的是，无论命名还是匿名管道，它的文件描述都没有偏移量的概念，所以不能用lseek进行偏移量调整。关于管道的其它议题，比如popen、pclose的使用等话题，《UNIX环境高级编程》中的相关章节已经讲的很清楚了。如果想学习补充这些知识，请参见此书。此文已由腾讯云+社区在各渠道发布获取更多新鲜技术干货，可以关注我们腾讯云技术社区-云加社区官方号及知乎机构号 ...

背景众所周知，日志是记录应用程序运行状态的一种重要工具，在业务服务中，日志更是十分重要。通常情况下，日志主要是记录关键执行点、程序执行错误时的现场信息等。系统出现故障时，运维人员一般先查看错误日志，定位故障原因。当业务流量小、逻辑复杂度低时，应用出现故障时错误日志一般较少，运维人员一般能够根据错误日志迅速定位到问题。但是，随着业务逻辑的迭代，系统接入的依赖服务不断增多，引入的组件不断增多，当系统出现故障时（如Bug被触发、依赖服务超时等等），错误日志的量级会急剧增加。极端情况下甚至出现“疯狂报错”的现象，这时候错误日志的内容会存在相互掩埋、相互影响的问题，运维人员面对报错一时难以理清逻辑，有时甚至顾此失彼，没能第一时间解决最核心的问题。错误日志是系统报警的一种，实际生产中，运维人员能够收到的报警信息多种多样。如果在报警流出现的时候，通过处理程序，将报警进行聚类，整理出一段时间内的报警摘要，那么运维人员就可以在摘要信息的帮助下，先对当前的故障有一个大致的轮廓，再结合技术知识与业务知识定位故障的根本原因。围绕上面描述的问题，以及对于报警聚类处理的分析假设，本文主要做了以下事情：选定聚类算法，简单描述了算法的基本原理，并给出了针对报警日志聚类的一种具体的实现方案。在分布式业务服务的系统下构造了三种不同实验场景，验证了算法的效果，并且对算法的不足进行分析阐述。目标对一段时间内的报警进行聚类处理，将具有相同根因的报警归纳为能够涵盖报警内容的泛化报警（Generalized Alarms），最终形成仅有几条泛化报警的报警摘要。如下图1所示意。我们希望这些泛化报警既要具有很强的概括性，同时尽可能地保留细节。这样运维人员在收到报警时，便能快速定位到故障的大致方向，从而提高故障排查的效率。设计如图2所示，异常报警根因分析的设计大致分为四个部分：收集报警信息、提取报警信息的关键特征、聚类处理、展示报警摘要。算法选择聚类算法采用论文“Clustering Intrusion Detection Alarms to Support Root Cause Analysis [KLAUS JULISCH, 2002]”中描述的根因分析算法。该算法基于一个假设：将报警日志集群经过泛化，得到的泛化报警能够表示报警集群的主要特征。以下面的例子来说明，有如下的几条报警日志：server_room_a-biz_tag-online02 Thrift get deal ProductType deal error.server_room_b-biz_tag-offline01 Pigeon query deal info error.server_room_a-biz_tag-offline01 Http query deal info error.server_room_a-biz_tag-online01 Thrift query deal info error.server_room_b-biz_tag-offline02 Thrift get deal ProductType deal error.我们可以将这几条报警抽象为：“全部服务器 网络调用 故障”，该泛化报警包含的范围较广；也可以抽象为：“server_room_a服务器 网络调用 产品信息获取失败”和“server_room_b服务器 RPC 获取产品类型信息失败”，此时包含的范围较小。当然也可以用其他层次的抽象来表达这个报警集群。我们可以观察到，抽象层次越高，细节越少，但是它能包含的范围就越大；反之，抽象层次越低，则可能无用信息越多，包含的范围就越小。这种抽象的层次关系可以用一些有向无环图（DAG）来表达，如图3所示：为了确定报警聚类泛化的程度，我们需要先了解一些定义：属性（Attribute）：构成报警日志的某一类信息，如机器、环境、时间等，文中用Ai表示。值域（Domain）：属性Ai的域（即取值范围），文中用Dom(Ai)表示。泛化层次结构（Generalization Hierarchy）：对于每个Ai都有一个对应的泛化层次结构，文中用Gi表示。不相似度（Dissimilarity）：定义为d(a1, a2)。它接受两个报警a1、a2作为输入，并返回一个数值量，表示这两个报警不相似的程度。与相似度相反，当d(a1, a2)较小时，表示报警a1和报警a2相似。为了计算不相似度，需要用户定义泛化层次结构。为了计算d(a1, a2)，我们先定义两个属性的不相似度。令x1、x2为某个属性Ai的两个不同的值，那么x1、x2的不相似度为：在泛化层次结构Gi中，通过一个公共点父节点p连接x1、x2的最短路径长度。即d(x1, x2) := min{d(x1, p) + d(x2, p) | p ∈ Gi, x1 ⊴ p, x2 ⊴ p}。例如在图3的泛化层次结构中，d(“Thrift”, “Pigeon”) = d(“RPC”, “Thrift”) + d(“RPC”, “Pigeon”) = 1 + 1 = 2。对于两个报警a1、a2，其计算方式为：例如：a1 = (“server_room_b-biz_tag-offline02”, “Thrift”), a2 = (“server_room_a-biz_tag-online01”, “Pigeon”), 则d(a1, a2) = d(“server_room_b-biz_tag-offline02”, “server_room_a-biz_tag-online01”) + d((“Thrift”, “Pigeon”) = d(“server_room_b-biz_tag-offline02”, “服务器”) + d(“server_room_a-biz_tag-online01”, “服务器”) + d(“RPC”, “Thrift”) + d(“RPC”, “Pigeon”) = 2 + 2 + 1 + 1 = 6。我们用C表示报警集合，g是C的一个泛化表示，即满足∀ a ∈ C, a ⊴ g。以报警集合{“dx-trip-package-api02 Thrift get deal list error.”, “dx-trip-package-api01 Thrift get deal list error."}为例，“dx服务器 thrift调用 获取产品信息失败”是一个泛化表示，“服务器 网络调用 获取产品信息失败”也是一个泛化表示。对于某个报警聚类来说，我们希望获得既能够涵盖它的集合又有最具象化的表达的泛化表示。为了解决这个问题，定义以下两个指标：H(C)值最小时对应的g，就是我们要找的最适合的泛化表示，我们称g为C的“覆盖”(Cover)。基于以上的概念，将报警日志聚类问题定义为：定义L为一个日志集合，min_size为一个预设的常量，Gi(i = 1, 2, 3……n) 为属性Ai的泛化层次结构，目标是找到一个L的子集C，满足 |C| >= min_size，且H(C)值最小。min_size是用来控制抽象程度的，极端情况下如果min_size与L集合的大小一样，那么我们只能使用终极抽象了，而如果min_size = 1，则每个报警日志是它自己的抽象。找到一个聚类之后，我们可以去除这些元素，然后在L剩下的集合里找其他的聚类。不幸的是，这是个NP完全问题，因此论文提出了一种启发式算法，该算法满足|C| >= min_size，使H(C)值尽量小。算法描述算法假设所有的泛化层次结构Gi都是树，这样每个报警集群都有一个唯一的、最顶层的泛化结果。将L定义为一个原始的报警日志集合，算法选择一个属性Ai，将L中所有报警的Ai值替换为Gi中Ai的父值，通过这一操作不断对报警进行泛化。持续步骤2的操作，直到找到一个覆盖报警数量大于min_size的泛化报警为止。输出步骤3中找到的报警。算法伪代码如下所示：输入：报警日志集合L，min_size，每个属性的泛化层次结构G1,……,Gn输出：所有符合条件的泛化报警T := L; // 将报警日志集合保存至表Tfor all alarms a in T do a[count] := 1; // “count"属性用于记录a当前覆盖的报警数量while ∀a ∈ T : a[count] < min_size do { 使用启发算法选择一个属性Ai; for all alarms a in T do a[Ai] := parent of a[Ai] in Gi; while identical alarms a, a’ exist do Set a[count] := a[count] + a’[count]; delete a’ from T;}其中第7行的启发算法为:首先计算Ai对应的Fifi(v) := SELECT sum(count) FROM T WHERE Ai = v // 统计在Ai属性上值为v的报警的数量Fi := max{fi(v) | v ∈ Dom(Ai)}选择Fi值最小的属性Ai这里的逻辑是：如果有一个报警a满足 a[count]>= min_size，那么对于所有属性Ai , 均能满足Fi >= fi(a[Ai]) >= min_size。反过来说，如果有一个属性Ai的Fi值小于min_size，那么a[count]就不可能大于min_size。所以选择Fi值最小的属性Ai进行泛化，有助于尽快达到聚类的条件。此外，关于min_size的选择，如果选择了一个过大的min_size，那么会迫使算法合并具有不同根源的报警。另一方面，如果过小，那么聚类可能会提前结束，具有相同根源的报警可能会出现在不同的聚类中。因此，设置一个初始值，可以记作ms0。定义一个较小的值 ℇ(0 < ℇ < 1)，当min_size取值为ms0、ms0 (1 - ℇ)、ms0 (1 + ℇ)时的聚类结果相同时，我们就说此时聚类是ℇ-鲁棒的。如果不相同，则使ms1 = ms0 * (1 - ℇ)，重复这个测试，直到找到一个鲁棒的最小值。需要注意的是，ℇ-鲁棒性与特定的报警日志相关。因此，给定的最小值，可能相对于一个报警日志来说是鲁棒的，而对于另一个报警日志来说是不鲁棒的。实现1. 提取报警特征根据线上问题排查的经验，运维人员通常关注的指标包括时间、机器（机房、环境）、异常来源、报警日志文本提示、故障所在位置（代码行数、接口、类）、Case相关的特殊ID（订单号、产品编号、用户ID等等）等。但是，我们的实际应用场景都是线上准实时场景，时间间隔比较短，因此我们不需要关注时间。同时，Case相关的特殊ID不符合我们希望获得一个抽象描述的要求，因此也无需关注此项指标。综上，我们选择的特征包括：机房、环境、异常来源、报警日志文本关键内容、故障所在位置（接口、类）共5个。2. 算法实现(1) 提取关键特征我们的数据来源是日志中心已经格式化过的报警日志信息，这些信息主要包含：报警日志产生的时间、服务标记、在代码中的位置、日志内容等。故障所在位置优先查找是否有异常堆栈，如存在则查找第一个本地代码的位置；如果不存在，则取日志打印位置。异常来源获得故障所在位置后，优先使用此信息确定异常报警的来源（需要预先定义词典支持）；如不能获取，则在日志内容中根据关键字匹配（需要预先定义词典支持）。报警日志文本关键内容优先查找是否有异常堆栈，如存在，则查找最后一个异常（通常为真正的故障原因）；如不能获取，则在日志中查找是否存在“code=……,message=……” 这样形式的错误提示；如不能获取，则取日志内容的第一行内容（以换行符为界），并去除其中可能存在的Case相关的提示信息提取“机房和环境”这两个指标比较简单，在此不做赘述。(2) 聚类算法算法的执行，我们以图4来表示。(3) min_size 选择考虑到日志数据中可能包含种类极多，且根据小规模数据实验表明，min_size = 1/5 报警日志数量时，算法已经有较好的表现，再高会增加过度聚合的风险，因此我们取min_size = 1/5 报警日志数量，ℇ参考论文中的实验，取0.05。(4) 聚类停止条件考虑到部分场景下，报警日志可能较少，因此min_size的值也较少，此时聚类已无太大意义，因此设定聚类停止条件为：聚类结果的报警摘要数量小于等于20或已经存在某个类别的count值达到min_size的阈值，即停止聚类。3. 泛化层次结构泛化层次结构，用于记录属性的泛化关系，是泛化时向上抽象的依据，需要预先定义。根据实验所用项目的实际使用环境，我们定义的泛化层次结构如下：“故障所在位置”此属性无需泛化层次结构，每次泛化时直接按照包路径向上层截断，直到系统包名。实验以下三个实验均使用C端API系统。1. 单依赖故障实验材料来自于线上某业务系统真实故障时所产生的大量报警日志。环境：线上故障原因：产品中心线上单机故障报警日志数量：939条部分原始报警日志如图9所示，初次观察时，很难理出头绪。经过聚类后的报警摘要如表1所示：IDServer RoomError SourceEnvironmentPosition （为保证数据安全，类路径已做处理）Summary （为保证数据安全，部分类路径已做处理）Count1所有机房产品中心Prodcom....CommonProductQueryClientcom.netflix.hystrix.exception.HystrixTimeoutException: commonQueryClient.getProductType execution timeout after waiting for 150ms.2492所有机房业务插件Prodcom....PluginRegistry.lambdajava.lang.IllegalArgumentException: 未找到业务插件:所有产品类型2403所有机房产品中心Prodcom....TrProductQueryClientcom.netflix.hystrix.exception.HystrixTimeoutException: TrQueryClient.listTrByDids2C execution timeout after waiting for 1000ms.1454所有机房对外接口(猜喜/货架/目的地)Prodcom....RemoteDealServiceImplcom.netflix.hystrix.exception.HystrixTimeoutException: ScenicDealList.listDealsByScenic execution timeout after waiting for 300ms.895所有机房产品中心Prodcom....CommonProductQueryClientcom.netflix.hystrix.exception.HystrixTimeoutException: commonQueryClient.listTrByDids2C execution timeout after waiting for 1000ms.296所有机房产品中心Prodcom....ActivityQueryClientImplcom.netflix.hystrix.exception.HystrixTimeoutException: commonQueryClient.getBusinessLicense execution timeout after waiting for 100ms.217所有机房产品中心prodcom....CommonProductQueryClientcom.netflix.hystrix.exception.HystrixTimeoutException: commonQueryClient.getBusinessLicense execution timeout after waiting for 100ms.218所有机房对外接口(猜喜/货架/目的地)Prodcom....RemoteDealServiceImplcom.netflix.hystrix.exception.HystrixTimeoutException: HotelDealList.hotelShelf execution timeout after waiting for 500ms.179所有机房产品中心Prodcom....TrProductQueryClientCaused by: java.lang.InterruptedException1610所有机房产品中心Prodcom....TrProductQueryClientCaused by: java.lang.InterruptedException13我们可以看到前三条报警摘要的Count远超其他报警摘要，并且它们指明了故障主要发生在产品中心的接口。2. 无相关的多依赖同时故障实验材料为利用故障注入工具，在Staging环境模拟运营置顶服务和A/B测试服务同时产生故障的场景。环境：Staging（使用线上录制流量和压测平台模拟线上正常流量环境）模拟故障原因：置顶与A/B测试接口大量超时报警日志数量：527条部分原始报警日志如图10所示：经过聚类后的报警摘要如表2所示：IDServer RoomError SourceEnvironmentPosition （为保证数据安全，类路径已做处理）Summary （为保证数据安全，部分类路径已做处理）Count1所有机房运营活动Stagingcom....ActivityQueryClientImpl[hystrix]置顶失败, circuit short is open2912所有机房A/B测试Stagingcom....AbExperimentClient[hystrix] tripExperiment error, circuit short is open1053所有机房缓存Stagingcom....CacheClientFacadecom.netflix.hystrix.exception.HystrixTimeoutException: c-cache-rpc.common_deal_base.rpc execution timeout after waiting for 1000ms.154所有机房产品信息Stagingcom....queryDealModelCaused by: com.meituan.service.mobile.mtthrift.netty.exception.RequestTimeoutException: request timeout145所有机房产品中心Stagingcom....CommonProductQueryClientcom.netflix.hystrix.exception.HystrixTimeoutException: commonQueryClient.getBusinessLicense execution timeout after waiting for 100ms.96所有机房产品中心Stagingcom....getOrderFormjava.lang.IllegalArgumentException: 产品无库存77所有机房弹性工程Stagingcom....PreSaleChatClientcom.netflix.hystrix.exception.HystrixTimeoutException: CustomerService.PreSaleChat execution timeout after waiting for 50ms.78所有机房缓存Stagingcom....SpringCacheManagerCaused by: java.net.SocketTimeoutException: Read timed out79所有机房产品信息Stagingcom....queryDetailUrlVOjava.lang.IllegalArgumentException: 未知的产品类型210所有机房产品信息Stagingcom....queryDetailUrlVOjava.lang.IllegalArgumentException: 无法获取链接地址1从上表可以看到，前两条报警摘要符合本次试验的预期，定位到了故障发生的原因。说明在多故障的情况下，算法也有较好的效果。3. 中间件与相关依赖同时故障实验材料为利用故障注入工具，在Staging环境模拟产品中心服务和缓存服务同时产生超时故障的场景。环境：Staging（使用线上录制流量和压测平台模拟线上正常流量环境）模拟故障原因：产品中心所有接口超时，所有缓存服务超时报警日志数量：2165部分原始报警日志如图11所示：经过聚类后的报警摘要如表3所示：IDServer RoomError SourceEnvironmentPosition （为保证数据安全，类路径已做处理）Summary （为保证数据安全，部分类路径已做处理）Count1所有机房SquirrelStagingcom....cacheTimeout4912所有机房CellarStagingcom....cacheTimeout2853所有机房SquirrelStagingcom....TdcServiceImplOther Exception1494所有机房评论Stagingcom....cacheTimeout1475所有机房CellarStagingcom....TdcServiceImplOther Exception1436所有机房SquirrelStagingcom....PoiManagerImpl熔断1127所有机房产品中心Stagingcom....CommonProductQueryClientOther Exception898所有机房评论Stagingcom....TrDealProcessorOther Exception839所有机房评论Stagingcom....poi.PoiInfoImplOther Exception8210所有机房产品中心Stagingcom....clientTimeout74从上表可以看到，缓存（Squirrel和Cellar双缓存）超时最多，产品中心的超时相对较少，这是因为我们系统针对产品中心的部分接口做了兜底处理，当超时发生时后先查缓存，如果缓存查不到会穿透调用一个离线信息缓存系统，因此产品中心超时总体较少。综合上述三个实验得出结果，算法对于报警日志的泛化是具有一定效果。在所进行实验的三个场景中，均能够定位到关键问题。但是依然存在一些不足，报警摘要中，有的经过泛化的信息过于笼统（比如Other Exception）。经过分析，我们发现主要的原因有：其一，对于错误信息中关键字段的提取，在一定程度上决定了向上泛化的准确度。其二，系统本身日志设计存在一定的局限性。同时，在利用这个泛化后的报警摘要进行分析时，需要使用者具备相应领域的知识。未来规划本文所关注的工作，主要在于验证聚类算法效果，还有一些方向可以继续完善和优化：日志内容的深度分析。本文仅对报警日志做了简单的关键字提取和人工标记，未涉及太多文本分析的内容。我们可以通过使用文本分类、文本特征向量相似度等，提高日志内容分析的准确度，提升泛化效果。多种聚类算法综合使用。本文仅探讨了处理系统错误日志时表现较好的聚类算法，针对系统中多种不同类型的报警，未来也可以配合其他聚类算法（如K-Means）共同对报警进行处理，优化聚合效果。自适应报警阈值。除了对报警聚类，我们还可以通过对监控指标的时序分析，动态管理报警阈值，提高告警的质量和及时性，减少误报和漏告数量。参考资料Julisch, Klaus. “Clustering intrusion detection alarms to support root cause analysis.” ACM transactions on information and system security (TISSEC) 6.4 (2003): 443-471.https://en.wikipedia.org/wiki…作者简介刘玚，美团点评后端工程师。2017 年加入美团点评，负责美团点评境内度假的业务开发。千钊，美团点评后端工程师。2017 年加入美团点评，负责美团点评境内度假的业务开发。 ...

环境准备：云主机（香港节点）（CentOS7.4）系统：CentOS7网卡名:eth0客户端（win7）（红米安卓手机）#由于pptpd需要iptables的支持，而centos7以后不再内置iptables服务了,所以需要下载iptables-services#下载相关软件包： yum -y install iptables-services pptpd配置httpd服务：#配置pptpd服务：vim /etc/pptpd.conf将配置文件末尾的#localip 192.168.0.1#remoteip 192.168.0.234-238,192.168.0.245前的#注释去掉并保存退出也可以自行更改分配的ip段然后配置用户信息vi /etc/ppp/chap-secrets#格式为：(其中*可设置为用户拨号后分配的ip)用户 pptpd 密码 *配置接入后分配的DNS，这里可以查看/etc/resolv.conf里面系统配置的DNS是多少，将其相应DNS配置进去最后一行追加dns配置，格式为：ms-dns ipvim /etc/ppp/options.pptpd开启防火墙转发：service start iptables #启动iptablesiptables -F #清空默认配置iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE #开启转发，里面的IP段为配置pptpd服务分配的IP段iptables -I FORWARD -p tcp –syn -i ppp+ -j TCPMSS –set-mss 1356 #更改mss值service iptables save #保存配置servicr iptables restart #重启iptables开启ipv4转发：echo “net.ipv4.ip_forward=1” >> /etc/sysctl.conf #开启ipv4转发sysctl -p #刷新配置启动服务并检查：systemctl start pptpd #启动服务systemctl status pptpd #查看服务状态lsof -i:1723 #端口检查客户端链接打开网络和共享中心，点击设置新的链接或网络选择链接到工作区选择使用我的Internet链接填写服务器IP，然后下一步填写用户名和密码下一步正常是可以建立连接的如果失败了可以按跳过，在属性里把链接类型该为pptpd试试！！排除某些云服务商可能有限制，可以在客户端telnet服务器的1723端口来检查链接是否可以建立

无监控、不运维运维行业有句话：“无监控、不运维”。是的，一点也不夸张，监控俗称“第三只眼”。没了监控，什么基础运维，业务运维都是“瞎子”。**开篇所以说监控是运维这个职业的第一步。尤其是在现在DevOps这么火的时候，用监控数据给自己撑腰，这显得更加必要。有人说运维是背锅侠，那么，有了监控，有了充足的数据，一切以数据说话，运维还需要背锅吗，所以作为一个运维工程师，如何构建一套监控系统是你的第一件工作。统一运维监控平台设计思路运维监控平台不是简单的下载一个开源工具，然后搭建起来就行了，它需要根据监控的环境和特点进行各种整合和二次开发，以达到与自己的需求完全吻合的程度。**那么下面就谈谈运维监控平台的设计思路。构建一个智能的运维监控平台，必须以运行监控和故障报警这两个方面为重点，将所有业务系统中所涉及的网络资源、硬件资源、软件资源、数据库资源等纳入统一的运维监控平台中，并通过消除管理软件的差别。数据采集手段的差别，对各种不同的数据来源实现统一管理、统一规范、统一处理、统一展现、统一用户登录、统一权限控制，最终实现运维规范化、自动化、智能化的大运维管理。架构设计智能的运维监控平台，设计架构从低到高可以分为6层，三大模块，如下图：设计架构从低到高可以分为6层数据收集层：位于最底层，主要收集网络数据、业务系统数据、数据库数据、操作系统数据等，然后将收集到的数据进行规范化并进行存储。数据展示层：位于第二层，是一个Web展示界面，主要是将数据收集层获取到的数据进行统一展示，展示的方式可以是曲线图、柱状图、饼状态等，通过将数据图形化，可以帮助运维人员了解一段时间内主机或网络的运行状态和运行趋势，并作为运维人员排查问题或解决问题的依据。数据提取层：位于第三层，主要是对从数据收集层获取到的数据进行规格化和过滤处理，提取需要的数据到监控报警模块，这个部分是监控和报警两个模块的衔接点。报警规则配置层：位于第四层，主要是根据第三层获取到的数据进行报警规则设置、报警阀值设置、报警联系人设置和报警方式设置等。报警事件生成层：位于第五层，主要是对报警事件进行实时记录，将报警结果存入数据库以备调用，并将报警结果形成分析报表，以统计一段时间内的故障率和故障发生趋势。用户展示管理层：**位于最顶层，是一个Web展示界面，主要是将监控统计结果、报警故障结果进行统一展示，并实现多用户、多权限管理，实现统一用户和统一权限控制。功能实现划分3大模块在这6层中，从功能实现划分，又分为三个模块，分别是数据收集模块、数据提取模块和监控报警模块，每个模块完成的功能如下：数据收集模块：此模块主要完成基础数据的收集与图形展示。数据收集的方式有很多种，可以通过SNMP实现，也可以通过代理模块实现，还可以通过自定义脚本实现。常用的数据收集工具有Cacti、Ganglia等。数据提取模块：此模板主要完成数据的筛选过滤和采集，将需要的数据从数据收集模块提取到监控报警模块中。可以通过数据收集模块提供的接口或自定义脚本实现数据的提取。监控报警模块：此模块主要完成监控脚本的设置、报警规则设置，报警阀值设置、报警联系人设置等，并将报警结果进行集中展现和历史记录。常见的监控报警工具有Nagios、Centreon等。思维导图

双主 + keepalived 是一个比较简单的 MySQL 高可用架构，适用于中小 MySQL 集群，今天就说说怎么用 keepalived 做 MySQL 的高可用。1 概述1.1 keepalived 简介简单地说，keepalived 就是通过管理 VIP 来实现机器的高可用的，在使用 keepalived 的情况下，只有一台服务器能够提供服务(通过 VIP 来实现)，当 Master 主机宕机后，VIP 会自动飘移到另一台服务器keepalived 采用 Master/Slave 模式, 在 Master 上设置配置文件的 VIP，当 Master 宕机后，VIP 自动漂移到另一台 keepalived 服务器上keepalived 可以用来做各种软件的高可用集群，它会一直检测服务器的状态，如果有一台服务器宕机，或工作出现故障，keepalived 将检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后 keepalived 自动将服务器加入到服务器群中。1.2 keepalived 配合双主keepalived 使用默认配置只能做到主机级别的高可用，但是我们的 MySQL 要做高可用至少要增加以下功能能够检测 MySQL 服务状态主节点 read_only=0，备节点 read_only=1切换时，备节点要等待主节点同步完成所以，keepalived 实现 MySQL 高可用需要使用自定义脚本来进行扩展2 环境准备2.1 数据库环境操作前已经准备好了一套主主架构数据库，搭建方法参考 MySQL集群搭建(2)-主主从模式节点信息IP系统端口MySQL版本节点读写说明10.0.0.247Centos6.533065.7.9Master读写主节点10.0.0.248Centos6.533065.7.9Standby只读,可切换为读写备主节点VIP 信息简称VIP类型RW-VIP10.0.0.237读写VIPMaster 参考配置[client]port = 3306default-character-set=utf8mb4socket = /data/mysql_db/test_db/mysql.sock[mysqld]datadir = /data/mysql_db/test_dbbasedir = /usr/local/mysql57tmpdir = /tmpsocket = /data/mysql_db/test_db/mysql.sockpid-file = /data/mysql_db/test_db/mysql.pidskip-external-locking = 1skip-name-resolve = 1port = 3306server_id = 2473306default-storage-engine = InnoDBcharacter-set-server = utf8mb4default_password_lifetime=0auto_increment_offset = 1auto_increment_increment = 2#### log ####log_timestamps=systemlog_bin = /data/mysql_log/test_db/mysql-binlog_bin_index = /data/mysql_log/test_db/mysql-bin.indexbinlog_format = rowrelay_log_recovery=ONrelay_log=/data/mysql_log/test_db/mysql-relay-binrelay_log_index=/data/mysql_log/test_db/mysql-relay-bin.indexlog_error = /data/mysql_log/test_db/mysql-error.log#### replication ####log_slave_updates = 1replicate_wild_ignore_table = information_schema.%,performance_schema.%,sys.%#### semi sync replication settings #####plugin_dir=/usr/local/mysql57/lib/pluginplugin_load = “rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"loose_rpl_semi_sync_master_enabled = 1loose_rpl_semi_sync_slave_enabled = 1Slave 参考配置[client]port = 3306default-character-set=utf8mb4socket = /data/mysql_db/test_db/mysql.sock[mysqld]datadir = /data/mysql_db/test_dbbasedir = /usr/local/mysql57tmpdir = /tmpsocket = /data/mysql_db/test_db/mysql.sockpid-file = /data/mysql_db/test_db/mysql.pidskip-external-locking = 1skip-name-resolve = 1port = 3306server_id = 2483306default-storage-engine = InnoDBcharacter-set-server = utf8mb4default_password_lifetime=0auto_increment_offset = 2auto_increment_increment = 2#### log ####log_timestamps=systemlog_bin = /data/mysql_log/test_db/mysql-binlog_bin_index = /data/mysql_log/test_db/mysql-bin.indexbinlog_format = rowrelay_log_recovery=ONrelay_log=/data/mysql_log/test_db/mysql-relay-binrelay_log_index=/data/mysql_log/test_db/mysql-relay-bin.indexlog_error = /data/mysql_log/test_db/mysql-error.log#### replication ####log_slave_updates = 1replicate_wild_ignore_table = information_schema.%,performance_schema.%,sys.%#### semi sync replication settings #####plugin_dir=/usr/local/mysql57/lib/pluginplugin_load = “rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"loose_rpl_semi_sync_master_enabled = 1loose_rpl_semi_sync_slave_enabled = 12.2 创建监控用的账号- 由于是测试环境，账号密码设置比较随便create user monitor@’localhost’ identified by ‘monitor’;grant all on . to monitor@’localhost’;flush privileges;2.3 安装 keepalived我们在 Master 和 Slave 上部署 keepalived1). yum 安装如果有对应的 yum 源，直接安装就可以了yum install -y keepalived2). 源码安装下载安装包, 下载地址 keepalived, 使用 1.2.24 版本举例# 安装依赖yum install -y gcc popt-devel openssl openssl-devel libssl-dev libnl-devel popt-devel libnfnetlink-devel# 下载包wget http://www.keepalived.org/software/keepalived-1.2.24.tar.gz# 解压安装tar -xvz -f keepalived-1.2.24.tar.gzcd keepalived-1.2.24./configure –prefix=/usr/local/keepalivedmake && make installcp /usr/local/keepalived/sbin/keepalived /usr/sbin/cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/mkdir /etc/keepalived/cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/3 配置高可用3.1 keepalived 配置打开 /etc/keepalived/keepalived.conf 文件, 按照实际情况加上下面的配置global_defs { router_id MYSQL_MM # 标识 vrrp_skip_check_adv_addr vrrp_strict # 严格执行 VRRP 协议规范 vrrp_garp_interval 0 vrrp_gna_interval 0}vrrp_script check_mysql { script “/bin/sh /etc/keepalived/keepalived_mysql_check.sh” # 检查脚本 interval 10 # 检查周期}vrrp_instance MYSQL_MM { state BACKUP # 都设为 BACKUP，避免起来后抢占 interface eth0 # 网卡名称，根据实际情况填写 virtual_router_id 243 # 用来区分 VRRP 组播的标记，取值 0-255 priority 100 advert_int 1 nopreempt # 设为非抢占 authentication { auth_type PASS auth_pass 1111 } # Master 节点可以注释掉下面语句，防止启动 keepalived 的时候执行脚本 notify_master “/bin/sh /etc/keepalived/keepalived_mysql_start.sh” # 变为 MASTER 时执行 virtual_ipaddress { 10.0.0.237 } # Slave 节点可以注释下面检查脚本，Slave 没有必要一直检查 track_script { check_mysql }}3.2 配置检查脚本打开 /etc/keepalived/keepalived_mysql_check.sh， 写入检测脚本#!/bin/sh# @Author: chengqm# MySQL 检测脚本MyPath=$(cd $(dirname $0); pwd)cd $MyPathThisTime=date '+%F %T'log_file=’/var/log/keepalived_mysql.log’# MySQL 连接方式，根据实际情况调整export MYSQL_PWD=‘monitor’MYSQL_USER=‘monitor’MYSQL_SOCKET="/data/mysql_db/test_db/mysql.sock"mysql_connect=“mysql -u${MYSQL_USER} -S${MYSQL_SOCKET} “# 美化输出function techo() { message=$1 message_level=$2 if [ -e $message_level ];then message_level=‘info’ fi echo “date '+%F %T' - [${message_level}] $message” >> $log_file}# 检查函数, 正常返回 0function check { ret=$mysql_connect -N -e 'select 1 as value' if [ $? -ne 0 ] || [ $ret -ne ‘1’ ];then return 1 else return 0 fi}function read_only { param=$1 $mysql_connect -e “set global read_only = ${param}” techo “设置是否只读 read_only ${param}”}# 失效转移function failover { techo “开始执行失效转移” # 1. 停止 keepalived killall keepalived # 2. 如果还能执行的话，设为 read_only read_only 1 if [ $? -eq 0 ];then # 3. 如果还能执行，kill 所有的连接 $mysql_connect -e “select concat(‘KILL ‘,id,’;’) from information_schema.processlist where user!=‘root’ AND db is not null into outfile ‘/tmp/kill.txt.${ThisTime}’;” if [ $? -eq 0 ];then $mysql_connect -e “source /tmp/kill.txt.${ThisTime};” fi fi # 4. 其他操作，比如说自动关机 techo “失效转移执行成功，当前数据库关闭访问”}# 有问题检查 4 次for ((i=1; i<=4; i ++)) do check if [ $? -eq 0 ];then techo “MySQL is ok” # 正常退出脚本 exit 0 else techo “Connection failed $i time(s)” sleep 1 fidonetecho ‘无法连接当前数据库’# 失效转移failover注意：脚本没有经过严格测试，需要根据实际情况调整3.3 配置提升为 Master 时执行的脚本打开 /bin/sh /etc/keepalived/keepalived_mysql_start.sh”, 写入脚本内容#!/bin/sh# @Author: chengqm# keepalived 变为 Master 时执行MyPath=$(cd $(dirname $0); pwd)cd $MyPathThisTime=date '+%F %T'log_file=’/var/log/keepalived_mysql.log’# MySQL 连接方式，根据实际情况调整export MYSQL_PWD=‘monitor’MYSQL_USER=‘monitor’MYSQL_SOCKET="/data/mysql_db/test_db/mysql.sock"mysql_connect=“mysql -u${MYSQL_USER} -S${MYSQL_SOCKET} “# 美化输出function techo() { message=$1 message_level=$2 if [ -e $message_level ];then message_level=‘info’ fi echo “date '+%F %T' - [${message_level}] $message” >> $log_file}# 检查函数, 正常返回 0function check { ret=$mysql_connect -N -e 'select 1 as value' if [ $? -ne 0 ] || [ $ret -ne ‘1’ ];then return 1 else return 0 fi}# 获取 slave status 的信息function slave_info() { tmp_file=/tmp/slave_info.tmp $mysql_connect -e ‘show slave status\G’ > /tmp/slave_info.tmp slave_sql=grep 'Slave_SQL_Running:' $tmp_file | sed 's/\s*//g' | tr "A-Z" "a-z" | awk -F":" '{print $2}' seconds_behind_master=grep 'Seconds_Behind_Master:' $tmp_file | sed 's/\s*//g' | tr "A-Z" "a-z" | awk -F":" '{print $2}' master_log_file=grep 'Master_Log_File:' $tmp_file | head -1 | sed 's/\s*//g' | tr "A-Z" "a-z" | awk -F":" '{print $2}' master_log_pos=grep 'Read_Master_Log_Pos:' $tmp_file | sed 's/\s*//g' | tr "A-Z" "a-z" | awk -F":" '{print $2}' relay_master_log_file=grep 'Relay_Master_Log_File:' $tmp_file | sed 's/\s*//g' | tr "A-Z" "a-z" | awk -F":" '{print $2}' exec_master_log_pos=grep 'Exec_Master_Log_Pos:' $tmp_file | sed 's/\s*//g' | tr "A-Z" "a-z" | awk -F":" '{print $2}'}# 设置是否可读function read_only { param=$1 $mysql_connect -e “set global read_only = ${param}” techo “设置是否只读 read_only ${param}”}# 处理数据同步function sync_master_log() { # 如果是数据一致性优先，等待同步完毕。如果是服务可用性优先，可以注销下面的代码 slave_info if [ $slave_sql == “yes” ];then techo “当前同步位置 Master ${master_log_file} ${master_log_pos}” techo “等待同步到 Master ${master_log_file} ${master_log_pos}” $mysql_connect -e “select master_pos_wait(’$master_log_file’, $master_log_pos);” > /dev/null techo “同步完毕” fi}techo “当前数据库提升为主库"checkif [ $? -ne 0 ];then techo “无法连接当前数据库” exit 1fi# 等待同步sync_master_log# 设为可写read_only 0注意：脚本没有经过严格测试，需要根据实际情况调整3.4 启动 keepalived由于配置了 BACKUP 模式，所以两个 keepalived 先起来的是主，先后在主备节点执行/etc/init.d/keepalived start检查 /var/log/message 日志，确认 keepalived 没有报错检查 Master IP 状态, 确认设置了 VIP[root@cluster01 shell]# ip addr1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether fa:16:3e🇩🇪80:33 brd ff:ff:ff:ff:ff:ff inet 10.0.0.247/16 brd 10.0.255.255 scope global eth0 inet 10.0.0.237/32 scope global eth0 inet6 fe80::f816:3eff:fede:8033/64 scope link valid_lft forever preferred_lft forever检查 MySQL 检测脚本执行情况，确认正常运行[root@cluster01 ~]# tail -f /var/log/keepalived_mysql.log …2019-01-28 15:04:18 - [info] MySQL is ok2019-01-28 15:04:28 - [info] MySQL is ok4 失效转移测试在 mytest 库里新建 nowdate 测试表，只有 id 和 ctime 字段，然后每秒插入一条数据[root@cluster03 ~]# while true; do date;mysql -h10.0.0.237 -P3306 -umytest -e ‘use mytest;insert into nowdate values (null, now());’; sleep 1;doneMon Jan 28 15:04:26 CST 2019Mon Jan 28 15:04:27 CST 2019…kill 掉 Master 进程killall mysqld查看旧 Master 日志2019-01-28 15:04:48 - [info] MySQL is ok2019-01-28 15:04:58 - [info] Connection failed 1 time(s)2019-01-28 15:04:59 - [info] Connection failed 2 time(s)2019-01-28 15:05:00 - [info] Connection failed 3 time(s)2019-01-28 15:05:01 - [info] Connection failed 4 time(s)2019-01-28 15:05:02 - [info] 无法连接当前数据库2019-01-28 15:05:02 - [info] 开始执行失效转移2019-01-28 15:05:02 - [info] 设置是否只读 read_only 12019-01-28 15:05:02 - [info] 失效转移执行成功，当前数据库关闭访问查看新 Master 日志2019-01-28 15:05:04 - [info] 当前数据库提升为主库2019-01-28 15:05:04 - [info] 当前同步位置 Master mysql-bin.000015 323382019-01-28 15:05:04 - [info] 等待同步到 Master mysql-bin.000015 323382019-01-28 15:05:04 - [info] 同步完毕2019-01-28 15:05:04 - [info] 设置是否只读 read_only 02019-01-28 15:05:05 - [info] MySQL is ok查看新 Master IP，确认 VIP 已经飘过来了[root@cluster02 ~]# ip addr1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether fa:16:3e:66:7e:e8 brd ff:ff:ff:ff:ff:ff inet 10.0.0.248/16 brd 10.0.255.255 scope global eth0 inet 10.0.0.237/32 scope global eth0 inet6 fe80::f816:3eff:fe66:7ee8/64 scope link valid_lft forever preferred_lft forever查看插入数据执行情况，大概有 12 秒是不可用的Mon Jan 28 15:04:51 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:04:52 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:04:53 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:04:54 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:04:55 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:04:56 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:04:57 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:04:58 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:05:00 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:05:01 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:05:02 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:05:03 CST 2019失效切换成功5 总结使用双主 + keepalived 的优点是部署简单，双主加半同步情况下，理论上不会丢数据，适用于中小型 MySQL 集群。缺点也比较明显，就是增加从节点的情况下，从节点不会主动切换同步对象，而且脚本需要自己实现，有一定风险。 ...

近日，Cloud Toolkit正式推出了面向 IntelliJ 和 Eclipse 两个平台的新款插件，本文挑选了其中三个重大特性进行解读，点击文末官网跳转链接，可查看详细的版本说明。本地应用一键部署到任何机器上IDE 内置的命令行终端文件上传到服务器添加机器到 IntelliJ 或 Eclipse 中需要重点提下的是，虽然这个插件是阿里云官方插件，但了解到我们的开发者，还有不少原来的机器，以及线下环境，因此，这个插件不仅仅适用于阿里云 ECS，任何支持标准 SSH 协议的机器，都适用滴！在 IntelliJ 或 Eclipse，可以通过插件提供的图形引导界面，将机器配置到 IDE 中去。内置终端 Terminal在 IDE 内，开发者可以直接通过内置的终端 Terminal，即可一键快速登陆远程服务器。部署应用到远程服务器Cloud Toolkit 帮助开发者将本地应用程序一键部署到线下自有 VM，或阿里云 ECS、EDAS 和 Kubernetes 中去。当您每次修改完代码后，是否正在经历反复地打包？采用 SCP 工具上传？使用XShell或SecureCRT登陆服务器？替换部署包？重启？现在开始，请把这些重复繁琐的工作交给 Cloud Toolkit 吧！部署到 ECS完成编码后，无需在一系列运维工具之间切换，只需在 Cloud Toolkit 的图形界面上选择目标 ECS 实例，即可将应用部署至 ECS 指定目录部署到线下自有 VM支持 SSH 标准协议，你甚至可以将应用部署到任意机器中去部署到 EDAS针对阿里云 EDAS 开发者， 可以将本地代码和云端应用进行关联，实现自动化的部署部署到 Kubernetes针对阿里云 Kubernetes 开发者， 可以将本地代码和云端容器进行关联，实现自动化的镜像上传和部署文件上传Cloud Toolkit 帮助开发者在 IDE 内，一键将本地或者远程 URL 文件上传到服务器指定目录下去，无需在各种 FTP、SCP 工具之间频繁切换。更为重要的是，文件上传完毕后，还支持命令执行，比如：文件解压缩、程序启动等。官网https://toolkit.aliyun.com文档中心https://yq.aliyun.com/articles/665049需求Bug反馈https://www.wenjuan.com/s/emIFb2/本文作者：银时，Cloud Toolkit产品经理，《从Paxos到ZooKeeper》作者。立即点击下载官网：https://toolkit.aliyun.com本文作者：中间件小哥阅读原文本文为云栖社区原创内容，未经允许不得转载。

本文已同步到github web前端开发中，需掌握的linux概念及常用命令,欢迎收藏，欢迎start前一段时间阅读了《鸟哥的linux私房菜》的部分章节，也做了一些笔记，就在我再次打开笔记时，发现很多命令这是啥东东，有的都忘了，不过从头看一遍自己的笔记，就很快想起来了，从我个人的角度，平时学习过程中，记笔记确实是必要的。所以想把自己整理出的这些笔记整理一下，也分享给大家。那从何说起呢？既然是讲linux笔记，那就先说一句吧，在linux中，一切皆文件。1. 环境变量环境变量（environment variables） 一般是指在操作系统中用来指定操作系统运行环境的一些参数，如：临时文件夹位置和系统文件夹位置等。环境变量是在操作系统中一个具有特定名字的对象，它包含了一个或者多个应用程序所将使用到的信息。查看环境变量的配置格式, 如查看$PS1(操作系统及当前用户的相关信息)的配置echo $PS1临时设置直接给$PS1赋值即可$PS1=’[\u@\h \w]$‘如需永久生效,则需要修改/etc/profile文件的配置export PS1="[\u@\h \t]$“然后执行,source命令即可(通常用于重新执行刚修改的初始化文件，使之立即生效，而不必注销并重新登录）source /etc/profilePATH环境变量命令存放的路径, 是系统创建好的, 供用户使用, 随时随地使用echo $PATH // 查看PATH环境变量在执行命令如 ls 的时候, 会在PATH中查找, 没有提示command not found命令软件可安装在如下目录中/bin/sbin/usr/bin/usr/sbin/usr/local/bin/usr/local/sbin2. 硬链接与软链接2.1 硬链接(Hard Link)在同一分区中, inode号码相同的文件互为硬链接, 硬链接也就是文件的入口， 一般都是系统默认创建的防止误删除, 创建硬链接只能给文件创建硬链接, 不能给目录创建硬链接创建硬链接：ln 源文件入口 创建的硬链接入口例如: 给 /test/a.txt 创建一个硬链接2.2 软连接(Symbolic Link)存放的源文件的位置(inode节点号与源文件不同)，相当于windows的快捷方式创建软链接：ln -s 源文件入口 创建的软链接入口例如: 给 /test/a.txt 创建一个软链接2.3 硬链接与软连接的区别互为硬链接的inode号相同软连接与源文件的inode的节点号不同,硬链接必须再同一个分区中, 软链接可跨文件系统不能对目录创建硬链接, 软链接可以(经常用)2.4 彻底删除一个文件硬链接数为0(rm -f 硬链接)进程调用数为0如何查看文件被哪个进程调用lsof | grep 文件名如果硬链接数为0, 但文件被进程调用, 重启对应的软件或服务即可3. vim编辑文件时的快捷键及编辑、保存、退出操作3.1 vim快捷键G : 文件的最后一行（非编辑INSERT状态下）gg : 文件的第1行（非编辑INSERT状态下）o : 当前行下面一行插入一个空行并进入编辑模式u : 撤销（非编辑INSERT状态下）C : 删除光标所在位置到行尾内容,并进入到编辑模式A : 快速到达当前行的结尾, 并今日到编辑模式3.2 编辑、保存、退出操作1.按键盘 i 进入编辑模式, 进行文件配置2.按键盘 esc 退出编辑模式3.输入:wq 保存并退出4.如果文件无改动时退出 :q4.如果文件有改动, 不想保存修改的文件, 输入:q!注意: vim编辑文件, 输入法必须在英文模式下4. /etc目录下的配置文件目录功能/etc/profile一般进行系统全局环境变量永久生效或别名的配置文件/etc/selinux/configselinux防火墙的配置文件/etc/init.d/iptablesiptables防火墙的配置文件/etc/sysconfig/i18n字符集的配置文件/etc/sysconfig/network-scripts/ifcfg-eth0网卡配置文件/etc/sysconfig/network可配置主机名/etc/hosts解析主机名与ip地址的对应关系/etc/bashrc别名配置文件5. 网卡(网络适配器)配置文件网卡配置文件的位置在/etc/sysconfig/network-scripts/ifcfg-eth0, 默认配置项包括:1. DEVICE: 网卡的名称2.TYPE: 网络类型3.UUID: 系统中给每个设备分配的标识符号, 在系统中唯一4.HWADDR: HardWare Address 网卡的硬件地址/mac地址/物理地址, 全世界唯一, 在生产网卡时就已经确定5.ONBOOT: 开机或重启网络的时候是否自启动6.NM_CONTROLLED: 网卡的配置文件是否受系统newwork服务这个软件控制, 如果系统或网络重新连接, 网卡就重启了7.BOOTPROTO: 网卡获取ip的方法1.static/none: 固定ip,需手动设置2.dhcp: 系统默认自动获取8.IPADDR: 网卡的ip地址9.NETMASK: 子网掩码, 决定了一个局域网中最多可以有多少台机器(255.255.255.0相当于PREFIX=24)10.GATEWAY: 网关 ？<span style=“color: red”>不太理解</span>6. 别名 alias6.1 查看linux中默认的别名设置执行alias命令即可alias输出如下: 6.2 别名设置6.2.1 临时生效临时设置命令的别名， 命令行直接alias + 命令 = “自定义命令"即可, 如alias rm=“echo xxx"在命令行中执行:rm /a.txt // 输出xxx a.txt注意: 1.当重新登录服务器后, 别名设置失败2.在设置别名后, 如与原来命令功能不同, 但还想使用的话, 则在执行命令前加’ ‘即可\rm a.txt //这时rm原有功能生效6.2.2 永久生效想要让别名无论是否重启服务器还是重新登录服务器都生效, 则需在 /etc/profile中，进行配置 alias rm=“echo xxx”, 然后执行命令:source /etc/profile这样，rm的别名设置将永久生效6.3 取消别名设置unalias rm7. linux下面安装软件方式7.1 yum是一个在Fedora和RedHat以及CentOS中的Shell前端软件包管理器, 在linux环境下, 就可以使用yum命令,前提是需要网络。特点:自动解决需要安装的软件的依赖需要网络yum install tree -y7.2 rpm在linux环境下, 就可以使用yum命令,不需要网络, 但是需要挂在光盘, 来提供软件包的库。1.把设备挂在到服务器的目录下mount /dev/chrom /mnt2.查看设备是否挂在成功df -h3. 执行rpm命令安装需要的软件包,如:rpm -ivh /mnt/Packages/lrzsz-0.12.20-27.1.el6.x86_64.rpm4.检查是否安装成功lrzsz软件包rmp -qa lrzsz5.可以查看安装的软件包中的内容(可执行命令):rpm -ql lrzsz6.rpm 删除安装的软件包:rpm -e lrzsz7.3 编译安装默认安装到/usr/local目录下, 需要自己安装依赖8. tar 打包压缩8.1 创建压缩包(1). 打包/etc目录到 /tmp/etc.tar.gztar zcvf /tmp/etc.tar.gz /etc// z 通过gzipg工具进行压缩// c create 创建压缩包文件// v verbose 显示压缩过程// f 指定文件(2). 打包/etc目录到 /tmp/etc.tar.gz 并排除掉/etc/servicestar zcvf /tmp/etc.tar.gz /etc –exclude=/etc/services8.2 查看压缩包内容tar tf /tmp/etc.tar.gz8.3 解压压缩包8.3.1 解压到当前路径tar xf /tmp/etc.tar.gz// 默认解压到当前路径8.3.2 解压到指定目录下tar xf /tmp/etc.tar.gz -C /ttt// -C 解压到指定目录下9. no space left on device 磁盘空间不足9.1. 查看磁盘各分区占用情况df -h9.2. 进入分区使用率最高的查看该分区下各文件block大小du -sh .| sort -h //一层一层排查，确认好后再删除9.3. 查看系统中inode占用磁盘情况df -ih // 主要是查看系统中的小文件// -i 显示inode号// -h 人可以阅读懂得显示9.4. 文件没有被彻底删除(硬链接数为0,但是文件被系统进程所调用)常用命令1. manformat and display the on-line manual pages 使用手册想查看哪个命令如何使用,如查看ls命令如何使用：man ls2. ipshow / manipulate routing, devices, policy routing and tunnels 显示网卡ip地址信息知识点:1. ip a // ip address 缩写3. whichshows the full path of (shell) commands 展示命令的完整路径查看madir命令的完整路径which mkdir4. pwdprint name of current/working directory 显示当前工作目录5. lslist directory contents 列出目录的所有内容5.1 列出/root目录下的所有目录及文件cd /rootls5.2 列出/root目录下的所有目录及文件，并显示文件的相关信息cd /rootls -l // 相当于ll, -l : use a long listing format, 展示文件详细信息6. mkdir-make directories 创建目录6.1. 创建 /data文件夹mkdir /data6.2. 用一条命令完成创建目录/my/test，既创建/my目录及/my/test目录mkdir -p /my/test知识点:-p –parents no error if existing, make parent directories as needed如果文件已经存在，新建时不报错如果需要创建多级文件夹，会一直创建到最底层的父级文件夹7. touchchange file timestamps 创建文件，修改文件时间戳在data下面建一个文件test.txttouch /data/test.txt8. cdcd -change direcory 切换目录8.1 进入/data/test目录cd /data/test8.2 返回上一层目录cd ..9. cp-copy files and directories 拷贝文件或目录9.1 把/data/test.txt文件拷贝到/tmp下cp /data/test.txt /tmp9.2 拷贝/data目录到/tmp目录下cp -r /data /tmp知识点:1. -r 参数表示递归复制目录，一层一层的复制2. -p 拷贝时,保持文件属性不变2. -a 相当于 -pdr9.3 拷贝/data目录到/tmp目录下, 保持文件属性不变cp -p /data /tmp10. mv-move (rename) files 移动或重命名文件10.1 把/data目录移动到/root下mv /data /root10.2 把/data/a.txt 重命名为b.txtcd /datamv a/txt b.txt11. rm-remove files or directories 删除文件或目录11.1 进入/root目录下的data目录，删除test.txt文件cd /root/datarm -f test.txt // -f “force”, 表示强制删除11.2 删除目录,删除/data/test目录rm -r /data/test // -r 删除目录12. echo-display a line of text 显示文本行12.1 为/data/test.txt增加内容为“I am studying linux.”echo “I am studing linux” > /data/test.txt知识点:“>” , 重定向，先清空文件内容，然后再追加到文件结尾”>>” ,追加重定向 把内容追加到文件结尾13. catconcatenate files and print on the standard output 连接文件并打印输出文件内容13.1 显示/test.txt的文件内容cat /test.txt13.2 与<<配合，追加多行内容到文件/a.txt中cat >>/a.txt<<EOFaaaabbbbccccEOF14. history命令可以用来显示曾执行过的命令history 15. df查看磁盘空间df -h // 查看blockdf -i //查看inode16. du查看文件目录下文件大小du -sh / //查看根目录下的所有文件大小17. sort排序sort -参数 文件-n // 按照数字顺序排序-r // 逆序-k // 根据第几列进行排序-h // 人可以读懂的信息, 根据文件大小 T>G>M>K 18. psprocess status 进程状态18.1查看所有node进程ps -ef | grep node19. findsearch for files in a directory hierarchy 在目录层次结构中, 查找文件19.1 在/data目录下查找a.txt文件find /data -type f -name “a.txt"知识点:-type 查找内容的类型f 表示要查找的内容为文件类型19.2 find与 管道符 “|“配合使用 在/data目录下查找a.txt文件，并删除find /data -type f name “a.txt” | xargs rm -rf20. grep-print lines matching a pattern 根据匹配的规则过滤文本内容20.1 输出test.txt文件中，包含aaa字符串的行grep “aaa” test.txt20.2输出test.txt文件中，不包含aaa字符串的行grep -v “aaa” test.txt // -v参数: –invert-match 过滤掉不匹配的行20.3 与管道符号配合使用，如过滤出命令历史记录中的所有cd命令history | grep cd21. awk21.1 已知文件/data目录下的test.txt文件内容为:aaabbbcccddd输出test.txt文件内容时，不包含bbb字符串:awk ‘!/bbb/’ /data/test.txt21.2 输出/data/text.txt的第二行awk ‘NR ==20’ /data/text.txt21.3 输出/data/text.txt的第二行到第三行awk ‘NR ==2, NR==3’ /data/text.txt22. sed用于过滤和转换文本的流编辑器22.1 /data/test.txt中内容为aaa，把/data/a.txt的内容替换为bbbsed -i ’s#aaa#bbb#g’ /data/test.txt 知识点:-i –in-place 替换固定用法, ’s#要被替换的内容#替换后的内容#g’. ‘#‘也可以使用‘@’等等符号，一般常用‘#’22.2 使用sed命令输出行，如输出/data目录下test.txt的第20行，第20到30行sed -n ‘20p’ /data/test.txtsed -n ‘20, 30p’ /data/test.txt23. pingsend ICMP ECHO_REQUEST packets to network hosts 检查网络是否连通本周根据记录的笔记，整理出了在web前端开发中，几个linux中的相关概念和常用的命令，用法也都比较基础，主要是方便查阅复习，同时分享给大家，更全的信息那当然是去查手册了。如有问题，请各位大神多多指出，谢谢。最后，让我们一起来ping一下百度吧，ping!! ping! ping!ping www.baidu.com ...

本文介绍了企业互联网开发及运维的一些实践，深入剖析了互联网项目开发及上线过程中的各种痛点及解决之道。一个互联网项目的上线并不是那么容易，需要经过很多的环节：从服务器的准备开始，紧接着是业务系统的搭建，搭建的过程中涉及到操作系统、依赖中间件、应用部署、配置修改等众多事情；搭建完毕后，进行业务的线上验证及各种场景的演练，并进行高并发的压力模拟测试，找出性能瓶颈，并不断进行问题修正、架构调整；最后进行灾备的演练，整理好自动化脚本，然后挑选灾备环境的某一组进行上线试运行，迎接上线运行真实用户压力的考验。回想每次新项目上线的过程，每次都是一次痛苦的折磨。花费这么长时间，根源究竟是什么？答案就是这里面太多的环节都是依赖人工去处理。那么我们该如何缩短交付周期呢？回到大家手上的互联网项目，当项目上线后，是不是就万事大吉了呢？庆功后，更多的事情才慢慢到来，随着业务的开展，用户量渐渐增加，高并发的场景也开始凸显。由于只是关注了业务系统本身的上线，与之相关的外围支撑系统并没有建设，这种状况下，根本无法了解系统的内部运行状况。当前到底有多少用户在访问系统、每台服务器正承受多大的压力、当前的业务量到底是多少？我们可以思考下，淘宝做双11活动的时候，交易量是如何统计的？京东做618活动，实时流量又是如何统计的？我们应该建设哪些外围支撑，才能做到系统不是黑盒？当线上业务系统出错的时候，是不是经常遇到无从下手的情况？这是因为随着业务规模的不断扩大，线上系统变的错综复杂，就像图中的电线一样，稍有不慎，就会起火！可能是网络问题、环境问题、代码问题、第三方API的问题等等，想要定位问题需要各种不同的技术栈，调用链路的追踪，没有科学的依据，几乎不可能。当线上出现的问题排解的差不多了，业务也稳定了，新的问题又来了。用户的活跃带来了流量的井喷式暴增，稍有不慎就会导致系统崩塌。这个时候，需要进行及时的扩容，拯救系统。但往往事与愿违，机器准备不到位、环境部署不够快、业务扩容不及时，导致扩容的成本居高不下。或者采取了自认为“明智”的讨巧做法，借用其他业务线的机器进行了扩容，但是你的业务系统跟兄弟系统环境是不一致的。新业务的侵入，导致了其他业务线环境的改变，反而造成了别的业务线瘫痪，真是城门失火、殃及池鱼。我们急需一致化的环境进行扩容，Docker是我们的救兵。面对如此多的问题，可以想象团队的状况会是怎样的？团队整天忙于救火，压力非常大。很多时候为了救火而救火，拆了东墙补西墙，代码更是纯粹为了解决问题而堆上去的，代码管理混乱，技术积累缺乏……在这种技术积累的情况下，老板又要开启一条新业务线。由于没有统一的项目模板，导致每次项目启动都是底层代码都要重写一遍。模块封装不够，导致本可以公用的模块，每个团队都要重新封装一次，研发资源的重复投入，使得研发成本居高不下。为了使一切更规范起来，我们需要一个稳定的底层支撑平台，保证业务的快速发展。做到快速开发新提出的需求，不断的迭代小版本，开发的过程中有一些通用的模板和经过验证的技术组件直接套用。开发完成后，能够快速部署上线，小版本持续集成。上线以后服务不要挂掉，出现问题能够快速定位。流量暴增的时候，能够及时感知，并实现快速扩容。服务状态可以不断检测，挂掉的时候，最好能够自动重启……我们再来看使用平台的价值和收益，首先持续集成的过程更加顺畅，其次平台的自动化将使运维人员的成本降低，再次基于DevOps的理念，将使得开发和运维在日常工作中高度协同，自动化的流程，让一切变得规范，新版本的迭代更快更强，线上运行的更加稳定可靠。iuap平台支持DevOps全生命周期管理，并提供了对应工具支撑。提供了DevOps的最佳实践和工具使用说明，提供组件库对研发成果进行管理。保证编码、构建、测试、预发布、部署、监控等各个环节的持续进行。对于快速开发，提供了一系列的开发工具、框架与组件、后端示例代码、前端模板等。并通过官网文档，进行知识的传递和反馈交流，社区化的响应开发者的各种难题。想要解决系统黑盒的问题，我们通过收集浏览器端用户点击情况和收集Nginx日志的方式，以索引库的方式进行性能数据存储，最终对大数据进行分析，展示相应的业务报表，可视化的查看系统的各项运行指标。线上出错，我们通过收集服务器端应用性能数据的方式，实时展示应用的调用拓扑图，并根据出现异常的请求，进行下钻，定位出具体出现问题的代码。Docker的镜像一致性，将业务运行所需的操作系统、依赖环境、业务war包等都统一封装到了一起，应用部署的时候，直接拉取镜像即可。业务规模小的时候，只需启动少量容器，业务规模上来后，可以执行扩容操作，再次拉取镜像，以Docker的形态启动更多的应用容器实例。从此不再担心大流量来袭时的束手无措。

近日，容器云管理面板URLOS更新了一个重大功能——快照备份，使用快照备份数据非常快速，只需1秒，而且恢复快照也不会中断当运行中的服务，快照体积也非常小（相比阿里云、腾讯的快照），使用起来相当舒爽！现在带大家体验一下，值得注意的是，要想使用快照功能，那么机器中必须配备两块硬盘，以阿里云主机为例，先加一个硬盘再说。阿里云最少要购买20G，购买后，首先要挂载硬盘选择要挂载到哪个实例上挂载完成后，通过SSH工具查看云主机硬盘信息，输入命令：fdisk -lOK，新硬盘添加成功！登录URLOS主控端 http://ip:9968 或 https://ip:8866，点击集群，选择【自动添加集群和节点】先填写云主机的SSH密码，再点击挂载硬盘这里要填写块存储设备，这个怎么填？我们之前通过fdisk -l命令查看了硬盘信息，把红框标注部分填进去如果你的主机内存不大于1G，请设置一下虚拟内存，如果内存为1G，则设置1G虚拟内存点击提交，等待节点部署完成。在URLOS应用市场中，几乎每一个应用都自带快照功能，下面以安装一个mysql服务和wordpress博客系统来做如何使用URLOS快照功能的说明。首先安装mysql5.7，这里不会详细讲解安装过程，详细过程可参考URLOS官方教程：https://www.urlos.com/center-…，现在直接看快照部分：目前该功能面向所有用户开放，但是免费版只能设置48小时的时间间隔，付费版则无限制。同样，在wordpress安装时也可以选择快照备份时间间隔如何管理快照，在已安装的服务后面，点击“更多”按钮，显示出快照列表和手动快照备份选项先看快照列表标红框的就是快照存放的目录，可以通过sftp工具去查看，如需要恢复快照，点击【恢复快照】即可，恢复时，程序会先对当前状态进行1次备份，然后再恢复成你指定的快照。URLOS除了支持自动快照外，还支持手动快照，手动快照时填写快照描述URLOS快照功能十分强大，尤其是自动快照，有了这个功能的保驾护航，相信你的网站数据安全又多了一份保障。值得注意的是，现阶段，网站服务和数据库是需要分别备份的，比如wordpress网站快照只是备份了网站文件内容，数据库方面另外在mysql服务中备份。而且数据库服务的快照是将当前服务里的所有数据库整体快照，恢复时也是整体恢复，所以，URLOS官方建议创建1个网站服务则对应创建1个数据库服务，这样能保证该网站数据库恢复时不影响其他网站的数据库。

本文是根据虎牙直播运维负责人张观石10月20日在msup携手魅族、Flyme、百度云主办的第十三期魅族开放日《虎牙直播平台SRE实践》演讲中的分享内容整理而成。张观石，拥有10余年网站开发、架构、运维经验；目前关注互联网服务可靠性系统工程、运维平台的规划建设、网站高可用架构等方面；在音视频传输质量评估、微服务运维方面积累了丰富的经验。目录一、 直播平台的架构及运维挑战 （一） 音视频传输流程及挑战 （二） 一个直播间的流程 （三） 直播平台的运维挑战 二、 我们的思考和运维实践 （一） Google SRE介绍 • SRE是什么 • Google SRE方法论（二） 我们的思考：运维的六种能力 （三） 我们的运维实践运维可靠性管理感知能力修复能力反脆弱能力保障能力安全能力虎牙直播介绍虎牙直播是以游戏为主要内容，涵盖娱乐、综艺、教育、户外、体育等多种内容的直播平台，2018年5月在纽交所上市。虎牙算是整个直播行业比较重视技术的一家公司，大家可以对比下几家平台观看体验，我们应该是最好的一家了。英雄联盟S8 是全球最大的电子竞技赛事，目前正在如火如荼进行，从今天开始进入了总决赛的淘汰赛阶段了。这会正在进行的是IG对KT队，IG是中国的队伍，今年共有3只中国对进入了8强，是历年最好的成绩，比赛很精彩，如果不来今天的分享，我可能在家看比赛，或是去公司值班了。欢迎大家到虎牙直播平台观看直播，为LPL加油！(发布此稿时，中国队IG已经获得了总决赛冠军，虎牙平台观众数也突破了历史新高，直播过程无较大故障发生)。今天的分享正好会讲到关于这次赛事的运维保障的技术。一般网站比如电商类网站用户是卖家+买家， 卖家先编辑商品信息，发布后买家刷新后再看到，是异步的，卖家可以慢慢改，错了可以慢慢调。直播平台上，一个主播开播出现在摄像头面前，可能有成千上万的人同时观看，主播不能有任何小动作，不能离开，重新开播代价太大了，10分钟不能播观众就跑了。要是互动不流畅，土豪也就不想看你了。主播更不可能停播配合我们运维人员做一些技术上的调整。如此看来，直播平台相对于传统网站还是有区别的。所以，这对运维的挑战就更大。直播平台技术是比较复杂的，首先是音视频处理本身有很多高深的技术，其实是大规模的观众和主播，还要对实时性要求特别高。今年英雄联盟总决赛S8是从韩国现场传送回国，传输路径也比较复杂。一、直播平台的架构及运维挑战（一）音视频传输流程及挑战音频流程是指平台从开播到观看一系列的流程。①开播主播多同时开播的主播数量非常多。②上行选择多图中，中间蓝色部分的线是可以支持上行的线路，每一个主播都可以到任何一条线路上，虎牙有自动调度，运维人员也可以进行调度，主播上行哪里。③ 转推路径多 确定一条上行线路后，还要互相转推到其他线路上，观众可以在任何一条线路看到主播的直播。④观众线路多 观众有很大的选择权，比如选择不同的清晰度、不同的线路，包括H5技术等，播放技术和观众选择不一样。⑤转码档位多⑥实时要求高今年，虎牙运维研究团队又做了P2P技术，架构又比以前复杂了很多。（二）一个直播间的流程上图是一个虎牙主播直播的流程。首先，主播可以选择一个开播方式（进程开播、桌面直播、摄像头开播、手游投屏、手游桌面、OBS、导播系统、VR直播、第三方推流等）进行直播，经过4种推流方式（HUYA、UDP、 YY、 RTMP、CDN），直推到某条线路上，转推多家CDN，从CDN边缘到中心，然后再选择转码率，最后分发到不同省、市的运营商，之后就到观众的客户端。（三）直播平台的运维挑战因为音视频本身的复杂度，加上业务的实时性，对运维造成很大的挑战。传统的运维可以对开源组件做部署、配置、优化、高可用部署等。而音视频技术变化很快，自成一个体系，主播端和观众端的逻辑性强，由于中间传输路线多，运维人员很难参与其中，所以我们必须换一种工作方式。google的SRE 给了我们很大的启发，我们在SRE的方法论指导下，比较深入地参与到了音视频传输业务中，虽然我们不叫SRE，还是叫业务运维，不过做法吸收了SRE的很多思路。今天要分享的也是这方面的内容，希望对大家有些启发。二我们的思考和运维实践（一）Google SRE介绍• SRE是什么S是Site/Service/Software，运维的对象，网站业务服务线上的服务R是reliability，关注可靠性，质量，理解为对外部最终用户的质量和价值E是Engineer工程师、Engineering工程化。运维的本质是人和机器参与的一项系统性工程，这种工程跟软件工程不太一样的是，我们是负责业务上线后稳定运营，可靠性、质量、成本等。有人比喻业务研发和运维的关系就像是：生孩子与养孩子，哪个更难哪个更容易呢？• Google SRE方法论：•关注研发工作，减少琐事•保障SLO&度量风险•做好监控及黄金指标•应急事件处理•变更管理•需求预测和容量规划•资源部署•效率与性能（二）我们的思考：运维的六种能力常有人问我们运维是做什么的，我们说是做质量、效率、成本 ，具体怎么做，要怎么做呢，几句话很难讲清楚。《SRE Google运维解密》这本书强调实践方法论，能落地，但不够体系，可能是由不同的人写不同的章节。我有机会顺着可靠性这条路径，找到了传统行业的可靠性研究，发现了另外一片世界。大家都以为SRE是google提出来的，其实传统行业的SRE已经存在了几十年了，已经成为了一门学科。我个人研究之后，认为这门学科讲得更体系更完整，于是希望能套到互联网的服务中来。我参照照传统行业一些可靠性的理论、对框架做了一些迁移，将自己的思考转化成了一个运维的思考框架，叫做运维的六种能力，将其分为以下6点：SER眼中的可靠性：规定条件规定时间内完成规定功能可靠性的两个故事：二战时某次美军近半飞机无法起飞，发现是某些电子管不可靠引起的。朝鲜战争中美军电子设备不可靠，维修成本比制造成本高了几倍。从而诞生了可靠性这门学科。①可靠性管理首先要分析目标业务的可靠性模型，然后画出可靠性逻辑框图，评估每个环节和总体的可靠性性，进行度量和评价，可以是定性的，也可以是定量的。②感知能力在业务上线、建立连接之后，学会如何感知其状态、变化及问题。③修复能力当可靠性在设计阶段不够完善时，修复能力可以帮助我们在用户没有感知的状态下修复故障。④反脆弱能力业务运行在一定内部或外部环境里，寻找脆弱点和风险点，然后对它的脆弱点进行分析，并设计出反脆弱的能力，最终推动业务研发修改技术架构。⑤保障能力很多业务需要具备保障能力，建立保障性的设计，实现快速交付资源和快速能力到位。⑥安全能力如何保证我们业务安全、数据安全。（三）我们的运维实践我们主要关注所负责业务的核心服务的核心指标，我们将每一条端到端链路都看做是一个服务，那么服务指标可以是成功率、延迟或其他，将指标能达到某个程度作为目标；研发和运维团队会对这个服务画出部署构架图、可靠性逻辑框图（见下图）；建立业务的可靠性模型，同时还会做一些FMECA；分析失败模式及其带来的影响，以及讨论设计解决方案；对一些关键的服务，要把故障树画出来，度量风险，选择优先风险，推动解决；可靠性是管理出来，是运维出来的，但首先是设计出来的，可靠性设计的方法包括避错、改错、容错等。下图是我们负责运维的同学画的P2P技术架构流程图。下图是主播上行经过的环节，这对运维人员做监控时有指导意义。逻辑框图越画越细，每个点都会分析、统计它的可靠性。1.可靠性管理的要点①如何识别风险可以从几个方面判断：复杂度；技术成熟度；重要程度；环境严酷程度②如何验证可靠性水平开发阶段前性能测试；上线压测；容量模型；改进测试；模拟故障测试等③实践建立可靠性指标大盘；黄金指标&SLO；主播上行APM；全链路的可靠性；多维度的析评估体系；日报，月报，实时可靠性等。2.感知能力什么是感知力，包括但不限于监控的覆盖度，告警的实时性，准确性，触达率，问题定位能力，趋势预测能力 。①监控、状态感知能力以监控数据作为基础，提高人工感知能力和机器感知能力，监控是感知的基础，监控指标多了，不能说就有了感知力，这远远不够。②故障感知能力帮助运维人员感知业务的状态、变化和其他问题③AIOps大多是加强运维感知能力大数据；智能告警自动化测试、压力测试拨测、APM日志trace可阅读，可分析3.修复能力 SRE是与故障做斗争的系统工程。程序写得再好，也很难达到完全不出故障。衡量修复能力-MTTR：对于大部分的故障，都应该知道它的故障模式，根据故障模式就可以制定故障预案（规定条件规定时间规定人进行修复），根据预案做出一些修复工具，即人工修复或智能自愈。当发生一些考虑不到的情况出现时，需要维修和技术保养，进行扩容或者优化。根据平均修复时间和最大修复时间进行修复评价。虎牙的一些实践：主播上行切换：从早期主播重新开播修复上行问题，到后台手工切换，到主播端自动切换。修复时间（MTTR）从半个小时缩短到5分钟，到秒级。观众调度系统：基于主播端，观众端调度，小运营商调度、无缝切换，按协议调度等，机房一键上下线。故障修复更高一级是自愈，这也是故障修复能力转化为软件架构设计的高度。4.反脆弱能力反脆弱的设计：保证服务在脆弱条件下的保持容忍范围内的健壮性。软件总是在不同环境运行、不同条件下运行，这个条件就是可靠性中“规定的条件”。环境总是有很多脆弱点，要做脆弱性分析、反脆弱设计，最后评估评审。互联网常见的脆弱性因素，有机房、运营商、网络、单机故障，业务突发事件负载高、流量大，也可能微服务请求超时。健壮性设计，容灾性设计、高可用的设计、资源冗余等。这也是google SRE种说的拥抱风险、度量风险、评估风险容忍能力。S8源流的反脆弱性设计5.保障能力 软件架构设计特性和计划的保障资源，能快速满足使用要求的能力。可靠性保障的设计，要做到无状态，可切换，可调度，可重试等，比如说我们怎么样实现替换一台故障机器，且要求在10分钟内提供业务服务。做可靠性保障要做一个闭环，分析目标、风险、脆弱性；设计SLO-感知还有保障、修复、演练。感知SLI的变化以及相关的子SLI的变化，尽快修复SLI退化情况，在设计时尽量考虑到各种脆弱条件，做出反脆弱的保障方案。我们的一些实践：•带宽资源保障：能分钟级实现带宽调度，能1分钟内实现切流•服务器保障：3分钟能拿到多个机房服务器3分钟能把核心服务部署起来保障能力需要架构设计、接口的设计我们在直播间的做了一些特殊设计保障能力是多方面能力的综合体现：•考验的是自动化的程度，要有支撑系统的保障，要有自动化工具的保障•要做人力和人员的规划，考验故障时人员到位时间•要做硬件、软件资源的供应保障•是对软件架构的要求，是否支持平滑扩容•要有演练，确保能执行6.安全能力安全是最基本的能力，也是最大的风险之一。数据安全：层出不穷的数据泄露事件，用户信息涉密事件。业务安全：优惠券被刷，支付漏洞，主播言行、登录风控等。用户安全：比如滴滴的安全事件。以上内容由张观石原创，转载联系 meixi.feng@msup.com.cn

刚接触Docker的时候，以为只是用来做运维。后来真正用的时候才发觉，这个Docker简直是个神器。不管什么开发场景都能轻松应付。想要什么环境都能随意生成，而且灵活性更高，更轻量，完美实现微服务的概念。什么是DockerDocker是一个开源的应用容器引擎，基于Go语言 并遵从Apache2.0协议开源。传统虚拟机技术是虚拟出一套硬件后，在其上运行一个完整操作系统，在该系统上再运行所需应用进程；而容器内的应用进程直接运行于宿主的内核，容器内没有自己的内核，而且也没有进行硬件虚拟。它占用的资源更少，能做到的事更多。与传统虚拟机的对比特性容器虚拟机启动秒级分钟级 硬盘启动一般为MB一般为GB性能接近原生弱于系统支持量单机支持上千个容器一般几十个安装Docker安装的方法都挺简单的，我用的是mac，直接通过Docker官网下载软件安装，全程无障碍。Docker概念镜像（images）：Docker镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。(直白点可以理解为系统安装包)容器（container）：镜像和容器的关系，就像是面向对象程序设计中的类和实例一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。（可以理解为安装好的系统）Docker镜像使用一、下载镜像大概了解了Docker的概念以后，我们就尝试拉取flask镜像使用一下。查找镜像可以通过https://hub.docker.com/网站来搜索，或者通过命令搜索。docker search flask在这里，我是通过Docker hub官网挑选出了python3.7 + alpine3.8组合的运行环境，alpine是精简版的linux，体积更小、运行的资源消耗更少。# 拉取镜像docker pull tiangolo/uwsgi-nginx-flask:python3.7-alpine3.8# 下载好可查看镜像列表是否存在docker images二、运行flask镜像下载镜像以后，就开始运行下试试，感受一下Docker的轻量、快捷。首先创建个flask运行文件来，在这里，我创建了/docker/flask作为项目文件，然后在根目录下再创建个app文件夹来存放main.py文件，代码如下：from flask import Flaskapp = Flask(name)@app.route("/")def hello(): return “Hello World from Flask!“if name == “main”: # 测试环境下才开启debug模式 app.run(host=‘0.0.0.0’, debug=True, port=80)现在的文件结构：flask └── app └── main.py运行命令docker run -it –name test -p 8080:80 -v /docker/flask/app:/app -w /app tiangolo/uwsgi-nginx-flask:python3.7-alpine3.8 python main.py这里说明一下命令的参数含义：-it 是将-i -t合并起来，作用是可以用指定终端对容器执行命令交互。–name 对容器进行命名。-p 将主机的8080端口映射到容器的80端口。-v 将主机的/docker/flask/app文件挂载到容器的/app文件，如果容器内没有的话会自动创建。-w 将/app文件作为工作区，后面的执行命令都默认在该文件路径下执行。tiangolo/uwsgi-nginx-flask:python3.7-alpine3.8 镜像名跟标签。python main.py 通过python来运行工作区的main.py文件。运行结果：现在主机跟容器的链接已经建立起来了，主机通过8080端口就能访问到容器的网站。自定义镜像在使用别人定制的镜像时总是不能尽善尽美的，如果在自己项目里面，不能每次都是拉取下来重新配置一下。像上面的镜像，我可不喜欢这么长的名字，想想每次要敲这么长的名字都头疼(tiangolo/uwsgi-nginx-flask:python3.7-alpine3.8)。编写Dockerfile文件打开我们刚才的/docker/flask路径，在根目录下创建Dockerfile文件，内容如下。# 基础镜像FROM tiangolo/uwsgi-nginx-flask:python3.7-alpine3.8# 没有vim来查看文件很不习惯，利用alpine的包管理安装一个来RUN apk add vim# 顺便用pip安装个redis包，后面用得上RUN pip3 install redis# 将我们的app文件加入到自定义镜像里面去COPY ./app /app现在我们的文件结构是：flask├── app│ └── main.py└── Dockerfile剩下的就跑一遍就OK啦！记得一定要在Dockerfile文件同级目录下执行build命令。docker build -t myflask .Sending build context to Docker daemon 4.608kBStep 1/4 : FROM tiangolo/uwsgi-nginx-flask:python3.7-alpine3.8 —> c69984ff0683Step 2/4 : RUN apk add vim —> Using cache —> ebe2947fcf89Step 3/4 : RUN pip3 install redis —> Running in aa774ba9030eCollecting redis Downloading https://files.pythonhosted.org/packages/f5/00/5253aff5e747faf10d8ceb35fb5569b848cde2fdc13685d42fcf63118bbc/redis-3.0.1-py2.py3-none-any.whl (61kB)Installing collected packages: redisSuccessfully installed redis-3.0.1Removing intermediate container aa774ba9030e —> 47a0f1ce8ea2Step 4/4 : COPY ./app /app —> 50908f081641Successfully built 50908f081641Successfully tagged myflask:latest-t 指定要创建的目标路径。. 这里有个点记住啦，表示是当前路径下的Dockerfile文件，可以指定为绝对路径。编译完后就通过docker images查看一下，就能看到myflask镜像了，里面能直接运行python main.py来启动flask，并且内置了vim和redis包。Docker Compose让多容器成为一个整体我们的每个容器都负责一个服务，这样容器多的时候一个个手动启动的话是不现实的。在这种情况我们可以通过Docker Compose来关联每个容器，组成一个完整的项目。Compose项目由Python编写，实现上调用了 Docker服务提供的 API 来对容器进行管理。# 安装docker-composesudo pip3 install docker-compose实现能记录访问次数的web在这里，我们通过docker-compose.yml文件来启动flask容器和redis容器，并将两个不同容器相互关联起来。首先在/docker/flask目录下创建docker-compose.yml文件，内容如下：version: ‘3’services: flask: image: myflask container_name: myflask ports: - 8080:80 volumes: - /docker/flask/app:/app working_dir: /app # 运行后执行的命令 command: python main.py redis: # 如果没有这个镜像的话会自动下载 image: “redis:latest” container_name: myredis然后我们把上面的main.py代码修改一下，连接redis数据库并记录网站访问次数。main.py修改后内容如下:from flask import Flaskfrom redis import Redisapp = Flask(name)redis = Redis(host=‘redis’, port=6379)@app.route(”/")def hello(): count = redis.incr(‘visit’) return f"Hello World from Flask! 该页面已被访问{count}次。“if name == “main”: # Only for debugging while developing app.run(host=‘0.0.0.0’, debug=True, port=80)目前的文件结构是：flask├── app│ └── main.py└── Dockerfile└── docker-compose.yml这些编排的文件参数都是取自于Docker，基本都能看懂，其它就没啥啦，直接命令行跑起来：docker-compose up就辣么简单!现在我们在浏览器上访问http://localhost:8080/就能看到结果了，并且每访问一次这页面都会自动增加访问次数.在这里，我们也能通过docker ps命令查看运行中的容器：docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES66133318452d redis:latest “docker-entrypoint.s…” 13 seconds ago Up 12 seconds 6379/tcp myredis0956529c3c9c myflask “/entrypoint.sh pyth…” 13 seconds ago Up 11 seconds 443/tcp, 0.0.0.0:8080->80/tcp myflask有了Docker Compose的Docker才是完整的Docker，有了这些以后开发简直不要太爽，每个容器只要维护自己的服务环境就ok了。Docker的日常操作镜像常用操作# 下载镜像docker pull name# 列出本地镜像docker images# 使用镜像运行生成容器docker run name:tag# 删除镜像docker rmi id/name容器常用操作可以通过容器的id或者容器别名来启动、停止、重启。# 查看运行中的容器docker ps# 查看所有生成的容器docker ps -a# 开始容器docker start container# 停止容器docker stop container# 重启容器docker restart container# 移除不需要的容器(移除前容器必须要处于停止状态)docker rm container# 进入后台运行的容器docker exec -it container /bin/sh# 打印容器内部的信息（-f参数能实时观察内部信息）docker logs -f container通过-i -t进来容器的，可以先按ctrl + p, 然后按ctrl + q来退出交互界面组，这样退出不会关闭容器。docker-compose常用操作# 自动完成包括构建镜像,（重新）创建服务，启动服务，并关联服务相关容器的一系列操作。docker-compose up# 此命令将会停止 up 命令所启动的容器，并移除网络docker-compose down# 启动已经存在的服务容器。docker-compose start# 停止已经处于运行状态的容器，但不删除它。通过start可以再次启动这些容器。docker-compose stop# 重启项目中的服务docker-compose restart默认情况，docker-compose up启动的容器都在前台，控制台将会同时打印所有容器的输出信息，可以很方便进行调试。当通过Ctrl-C停止命令时，所有容器将会停止。结语这次接触Docker的时间虽然不长，但是这种微服务细分的架构真的是惊艳到我了。以前玩过VM虚拟机，那个使用成本太高，不够灵活，用过一段时间就放弃了，老老实实维护自己的本机环境。有了这个Docker以后，想要什么测试环境都行，直接几行代码生成就好，一种随心所欲的自由。上面写的那些都是日常使用的命令，能应付基本的需求了，真要深入的话建议去找详细的文档，我就不写太累赘了，希望大家都能去接触一下这个Docker，怎么都不亏，你们也会喜欢上这小鲸鱼的。 ...

2019年即将到来，各位同学2018年辛苦了。 不管大家2018年过的怎么样，2019年还是要继续加油的！ 在此我整理了个人认为在2019仍是或者将成为主流的技术与大家分享，包括前端、后端和全栈相关。工具、软件欲先攻其事必先利其器，用好工具是做好开发的基础。编辑器／IDE： VSCode，Sublime Text，Atom浏览器：Chrome，Firefox设计／原型：Adobe XD，Photoshop，Sketch，Figma命令行工具：Git Bash，WSL，iTerm2，Hyper版本管理：Git前端前端我觉得是每个做web开发的同学都应该掌握的，就算是做后端开发的，基本的前端知识也是必不可少的。HTML & CSSHTML5CSS3Flexbox (简易教程)，CSS Grid (简易教程)CSS Variables (Custom Properties)响应式布局（Responsive Layout）设置ViewportMedia queryrem-based layoutMobile First DesignSassStructured CSSVariablesNested CSSMixins & FunctionsInheritanceJavascriptData Types, functions, conditionals, loops, operatorsDOM操作，EventsJSONFetch APIES6+ (arrow function, promise, async / await, destructuring…)HTML / CSS 框架html／css将被逐渐弱化，但是掌握一两个流行框架还是有必要的。BootstrapMaterializeBulmaJS框架React：目前最流行Vue：简单易用，越来越多人用Angular：曾经很流行，现在有点衰退状态管理（state management）ReduxVueXNgRxApollo (GraphQL Client)后端渲染（server side rendering）Next.js (React)Nuxt.js (Vue)Angular Universal (Angular)开发工具依赖管理：NPM，Yarn应用打包：Webpack，Parcel任务管理：Gulp，Grunt编辑器扩展：ESLint，Live Server，Prettier移动端有了前端的知识后，我们还可以开发手机app。React Native：使用react开发原生应用NativeScript：使用Angular／TypeScript／Javascript开发原生应用Ionic：使用html／css／js开发混合应用Flutter：使用Dart语言开发原生应用Xamarin：使用C#开发原生应用桌面端甚至桌面app！Electron：使用chromium和node.js，兼容windows，mac，linux后端语言前端同学如果想成为全栈，学一门后端语言是必不可少。Node.Js：就算不做全栈，nodejs也将成为前端的必备技能Python：如果除了web开发想往人工智能、机器学习、数据分析方向扩展的同学，python更合适C#：个人很喜欢的语言，非常优雅和高效Go：越来越流行的语言，有很强大的标准库，减轻对第三方的依赖PHP：虽然很多人觉得shitty，但是不得不承认太多网站都是php写的，wordpress实在太流行了后端框架Node.js：Express，Koa，AdonisPython：Django，FlaskC#：ASP.NETPHP：Laravel，Symfony数据库关系型：MySQL，PostgreSQL，MS SQLNoSQL：MongoDB，Couchbase云存储：Firebase，AWS，Azure Cosmos DB轻量级：SQLite，NeDB，RedisCMS（Content Management System）如果不想自己开发网站的时候，用个现成的CMS系统也是不错的。PHP：WordPress，DrupalJS：Ghost，KeyStonePython：Mezzazine.NET：Piranha，Orchard CMS运维基础基本的运维知识也是需要的，不然自己写个网站搞不上线多着急。注册域名：Namecheap，Google DomainsFTP，SFTP文件上传：Filezilla，Cyberduck部署：Linux，SSH，Git，web服务器（Nginx，Apache）虚拟化：Docker，Vagrant静态托管服务：Netlify，Github Pages托管共享主机 & VPS：Inmotion，Hostgator, Bluehost云平台：Digital Ocean，AWS，Heroku，Azure其他GraphQL & ApolloGraphQL简而言之是一种API 查询语言（QL = query language），提供了一种革命性的API实现方式。GraphQL是一种规范（specification）而不是实现（implementation）。而Apollo是GraphQL最火的实现。更多请参考：Awesome GraphQL。TypeScriptTypeScript诞生已经有好几年了，近两年变得很火，很多框架和工具都是typescript写的，比如vscode，angular，ant-design，更多请参考 github。对于想开发框架或者库的同学typescript很值得学，但是优先精通es6+babel的开发方式。PWA (Progressive Web Apps)用户体验是个永恒的话题，大家都想使用体验如原生应用的网站，所以PWA是个必然的趋势。更多请参考 github awesome PWAWebAssembly或许WebAssembly可能不会取代javascript，但是当所有人都开始谈论它的时候，为了好奇心也要学一下。。 ...

本文由云+社区发表TCP是一个复杂的协议，每个机制在带来优势的同时也会引入其他的问题。 Nagel算法和delay ack机制是减少发送端和接收端包量的两个机制， 可以有效减少网络包量，避免拥塞。但是，在特定场景下， Nagel算法要求网络中只有一个未确认的包， 而delay ack机制需要等待更多的数据包， 再发送ACK回包， 导致发送和接收端等待对方发送数据， 造成死锁， 只有当delay ack超时后才能解开死锁，进而导致应用侧对外的延时高。 其他文字已经介绍了相关的机制， 已经有一些文章介绍这种时延的场景。本文结合具体的tcpdump包，分析触发delay ack的场景，相关的内核参数， 以及规避的方案。背景给redis加了一个proxy层， 压测的时候发现， 对写入命令，数据长度大于2k后， 性能下降非常明显， 只有直连redis-server的1/10. 而get请求影响并不是那么明显。分析观察系统的负载和网络包量情况， 都比较低， 网络包量也比较小， proxy内部的耗时也比较短。 无赖只能祭出tcpdump神奇， 果然有妖邪。22号tcp请求包， 42ms后服务端才返回了ack。 初步怀疑是网络层的延时导致了耗时增加。Google和km上找资料， 大概的解释是这样： 由于客户端打开了Nagel算法， 服务端未关闭延迟ack， 会导致延迟ack超时后，再发送ack，引起超时。原理Nagel算法，转自维基百科if there is new data to send if the window size >= MSS and available data is >= MSS send complete MSS segment now else if there is unconfirmed data still in the pipe enqueue data in the buffer until an acknowledge is received else send data immediately end if end ifend if简单讲， Nagel算法的规则是：如果发送内容大于1个MSS， 立即发送；如果之前没有包未被确认， 立即发送；如果之前有包未被确认， 缓存发送内容；如果收到ack， 立即发送缓存的内容。延迟ACK的源码如下：net/ipv4/tcp_input.c基本原理是：如果收到的数据内容大于一个MSS， 发送ACK；如果收到了接收窗口以为的数据， 发送ACK；如果处于quick mode， 发送ACK；如果收到乱序的数据， 发送ACK；其他， 延迟发送ACK其他都比较明确， quick mode是怎么判断的呢？ 继续往下看代码：影响quick mode的一个因素是 ping pong的状态。 Pingpong是一个状态值， 用来标识当前tcp交互的状态， 以预测是否是W-R-W-R-W-R这种交互式的通讯模式， 如果处于， 可以用延迟ack， 利用Read的回包， 将Write的回包， 捎带给发送方。如上图所示， 默认pingpong = 0， 表示非交互式的， 服务端收到数据后， 立即返回ACK， 当服务端有数据响应时，服务端将pingpong = 1， 以后的交互中， 服务端不会立即返回ack，而是等待有数据或者ACK超时后响应。问题按照前面的的原理分析，应该每次都有ACK延迟的，为什么我们测试小于2K的数据时， 性能并没有受到影响呢？继续分析tcpdump包：按照Nagel算法和延迟ACK机制， 上面的交互如下图所示， 由于每次发生的数据都包含了完整的请求， 服务端处理完成后， 向客户端返回命令响应时， 将请求的ACK捎带给客户端，节约一次网络包。再分析2K的场景：如下表所示， 第22个包发送的数据小于MSS， 同时，pingpong = 1， 被认为是交互模式， 期待通过捎带ACK的方式来减少网络的包量。 但是， 服务端收到的数据，并不是一个完整的包，不能产生一次应答。服务端只能在等待40ms超时后，发送ACK响应包。 同时，从客户端来看，如果在发送一个包， 也可以打破已收数据 > MSS的限制。 但是，客户端受Nagel算法的限制， 一次只能有一个包未被确认，其他的数据只能被缓存起来， 等待发送。触发场景一次tcp请求的数据， 不能在服务端产生一次响应，或者小于一个MSS规避方案只有同时客户端打开Nagel算法， 服务端打开tcp_delay_ack才会导致前面的死锁状态。 解决方案可以从TCP的两端来入手。服务端：关闭tcp_delay_ack, 这样， 每个tcp请求包都会有一个ack及时响应， 不会出现延迟的情况。 操作方式： echo 1 > /proc/sys/net/ipv4/tcp_no_delay_ack 但是， 每个tcp请求都返回一个ack包， 导致网络包量的增加，关闭tcp延迟确认后， 网络包量大概增加了80%，在高峰期影响还是比较明显。2.设置TCP_QUICKACK属性。 但是需要每次recv后再设置一次。 对应我们的场景不太适合，需要修改服务端redis源码。客户端：关闭nagel算法，即设置socket tcp_no_delay属性。static void _set_tcp_nodelay(int fd) { int enable = 1; setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, (void*)&enable, sizeof(enable)); } 避免多次写， 再读取的场景， 合并成一个大包的写；避免一次请求分成多个包发送， 最开始发送的包小于一个MSS，对我们的场景， 把第22号包的1424个字节缓存起来， 大于一个MSS的时候，再发送出去， 服务端立即返回响应， 客户端继续发送后续的数据， 完成交互，避免时延。此文已由作者授权腾讯云+社区发布 ...

xin片之争，已经暴露了中国xin的问题，我等码农束手无策；而在操作系统方面，成果也是乏善可陈；现如今酷炫的Web监控工具，让很多研发丧失了真正处理问题的能力。越接近底层，就越接近真相，在计算机的世界，同样适用。我们的目的，就像是《荒岛余生》一样：找到一个信念，在最残酷的环境中，生存下去。说的比较隐晦，其实就是：你换公司了，而你的新公司比较推崇devops，你要自己面对问题。吹的那么高大上，一副拯救世界的感觉，但本系列的文章知识并不深，很多已经在大学里的操作系统见过了，虽然照读课本的叫兽并不能让你勾起丝毫兴趣。如果本系列能够勾起你的些许兴趣，就算目的达到了。本来是想要聊仔细点，但由于时间有限，又不是写书，原理性的东西就不多说了。内容文章将会尝试单纯的Cpu、Mem、Net、Disk、IO问题排查，然后组合各种元素，解决一些棘手问题，就是一些常用命令的组合。当然我们是java系的，所以会多一些java方面的讨论。如果你不了解行文风格，可以先读读：《Java堆外内存排查小结–小姐姐味道》为什么Linux系统会出现这样那样的问题呢？主要的原因就是计算机的各个部件的速度不均衡。Cpu在等cache line，cache 在等内存，内存在等设备。就像在连续17公里高速下坡路口设个收费站一样，一不小心就车毁人亡。设备五花八门，通常我们接触的设备，就是硬盘和网卡。整个业务系统和操作系统充斥着各种各样的缓冲区，CPU要通过中断负责他们之间的协调。这样，会有很多地方会发生bottleneck。监控值排查问题也是有过程的。通常，关注一个硬件资源，比如CPU，我们关注以下基本要素：1) 利用率 一般是瞬时值，属于采样范围，用来判断有没有峰值。比如cpu utilization2) 饱和度 一般指资源已完全使用，新请求在特定queue里排队。比如cpu load过高3) 错误信息 硬件或者驱动错误，比如dmesg命令显示的OOM4) 联想信息 对引起的原因进行猜测，并用更多的工具验证猜想。比如系统响应慢猜测大量用到了swap原因监控值只是一种表象，具体引起的原因才是重点。我们通常希望纯粹的资源限制所引起的故障，这种问题都比较好定位。大多数情况下都没那么幸运，所以广度上的信息共享能帮助很多。过程如下：1) 信息收集 问题起始时间，上下文2) 改动集合 问题发生前所有变更列表3) 问题抽象 将描述抽象成具体的资源问题4) 问题排查 将信息整理完毕，就可以进行真正的荒野之旅了测试本测试用来决定你是不是本文目标受众，如果无法回答以下问题，建议先看一点基本的Linux知识，这将会节省你的时间，因为文章不会对此提太多。io wait 是什么意思?swap是什么分区，怎么关闭?/tmp目录有什么特殊性?管道是什么东东?Linux发行版接下来热热身，瞧瞧Linux有什么发行版。我这里挑选了6个代表性的版本，版本聚焦的功能向专业化和个性化发展。其中，Centos作为最常见的服务器版本，占据了大量的市场份额；Ubuntu在GUI和易用性上赢得了桌面用户；Kali代表了向专业化发展的一个分支。个人使用时间最长的是archlinux，尤其喜欢它的滚动升级功能。但由于Centos在服务器端的市场份额实在太大，我们以下的讨论都基于Centos。据不完全统计，已经有上千个linux版本，见下图（高清大图见 https://distrowatch.com/image… ）。你来告诉我，红旗、麒麟的位置在哪里。将常用脚本加入到PATH中有些命令组合不好记，频繁输入也觉得烦，可以将这些过程整理成脚本，扔到path中。还记得第一次安装jdk，添加的环境变量么？Linux和它类似，不过它有多种shell。通常我们用的叫bash，平常说的shell脚本就是bash脚本。但也有很多其他好用的shell，比如csh、ksh、zsh等。查看/etc/shells文件看一下你安装过的shell[root@localhost ~]$ cat /etc/shells/bin/sh/bin/bash/bin/zsh/sbin/nologin/bin/dash在个人领域，zsh配合oh-my-zsh（推荐）达到最佳，但服务器一般不会去改你的shell，通过一个环境变量，能够看到你当前所使用的shell终端。[root@localhost ~]$ echo $SHELL/bin/bash针对于bash，我们的配置就在用户目录下的.bashrc文件中。在用户目录下创建.bin目录mkdir /.bin将目录加入到环境变量PATH中echo “export PATH=$PATH:/.bin/” >> ~/.bashrc在.bin创建一个文件xjj，内容为echo “pleasant taste"cat > ~/.bin/xjj <<EOFecho “pleasant taste"EOF给xjj增加可执行权限chmod a+x ~/.bin/xjj 这样，使用你的用户，在任何地方，都可以执行xjj了[root@localhost ]$ xjjpleasant taste真是令人愉悦的味道

从自动化到智能化运维过渡时，美团DBA团队进行了哪些思考、探索与实践？本文根据赵应钢在“第九届中国数据库技术大会”上的演讲内容整理而成，部分内容有更新。背景近些年，传统的数据库运维方式已经越来越难于满足业务方对数据库的稳定性、可用性、灵活性的要求。随着数据库规模急速扩大，各种NewSQL系统上线使用，运维逐渐跟不上业务发展，各种矛盾暴露的更加明显。在业务的驱动下，美团点评DBA团队经历了从“人肉”运维到工具化、产品化、自助化、自动化的转型之旅，也开始了智能运维在数据库领域的思考和实践。本文将介绍美团点评整个数据库平台的演进历史，以及我们当前的情况和面临的一些挑战，最后分享一下我们从自动化到智能化运维过渡时，所进行的思考、探索与实践。数据库平台的演变我们数据库平台的演进大概经历了五个大的阶段：第一个是脚本化阶段，这个阶段，我们人少，集群少，服务流量也比较小，脚本化的模式足以支撑整个服务。第二个是工具化阶段，我们把一些脚本包装成工具，围绕CMDB管理资产和服务，并完善了监控系统。这时，我们的工具箱也逐渐丰富起来，包括DDL变更工具、SQL Review工具、慢查询采集分析工具和备份闪回工具等等。第三个是产品化阶段，工具化阶段可能还是单个的工具，但是在完成一些复杂操作时，就需要把这些工具组装起来形成一个产品。当然，并不是说这个产品一定要做成Web系统的形式，而是工具组装起来形成一套流程之后，就可以保证所有DBA的操作行为，对流程的理解以及对线上的影响都是一致的。我们会在易用性和安全性层面不断进行打磨。而工具产品化的主要受益者是DBA，其定位是提升运维服务的效率，减少事故的发生，并方便进行快速统一的迭代。第四个是打造私有云平台阶段，随着美团点评业务的高速发展，仅靠十几、二十个DBA越来越难以满足业务发展的需要。所以我们就把某些日常操作开放授权，让开发人员自助去做，将DBA从繁琐的操作中解放出来。当时整个平台每天执行300多次改表操作；自助查询超过1万次；自助申请账号、授权并调整监控；自助定义敏感数据并授权给业务方管理员自助审批和管理；自定义业务的高峰和低峰时间段等等；自助下载、查询日志等等。第五个是自动化阶段，对这个阶段的理解，其实是“仁者见仁，智者见智”。大多数人理解的自动化，只是通过Web平台来执行某些操作，但我们认为这只是半自动化，所谓的自动化应该是完全不需要人参与。目前，我们很多操作都还处于半自动化阶段，下一个阶段我们需要从半自动过渡到全自动。以MySQL系统为例，从运维角度看包括主从的高可用、服务过载的自我保护、容量自动诊断与评估以及集群的自动扩缩容等等。现状和面临的挑战下图是我们平台的现状，以关系数据库RDS平台为例，其中集成了很多管理的功能，例如主从的高可用、MGW的管理、DNS的变更、备份系统、升级流程、流量分配和切换系统、账号管理、数据归档、服务与资产的流转系统等等。而且我们按照逻辑对平台设计进行了划分，例如以用户维度划分的RDS自助平台，DBA管理平台和测试环境管理平台；以功能维度划分的运维、运营和监控；以存储类型为维度划分的关系型数据库MySQL、分布式KV缓存、分布式KV存储，以及正在建设中的NewSQL数据库平台等等。未来，我们希望打造成“MySQL+NoSQL+NewSQL，存储+缓存的一站式服务平台”。挑战一：RootCause定位难即便我们打造了一个很强大的平台，但还是发现有很多问题难以搞定。第一个就是故障定位，如果是简单的故障，我们有类似天网、雷达这样的系统去发现和定位。但是如果故障发生在数据库内部，那就需要专业的数据库知识，去定位和查明到底是什么原因导致了故障。通常来讲，故障的轨迹是一个链，但也可能是一个“多米诺骨牌”的连环。可能因为一些原因导致SQL执行变慢，引起连接数的增长，进而导致业务超时，而业务超时又会引发业务不断重试，结果会产生更多的问题。当我们收到一个报警时，可能已经过了30秒甚至更长时间，DBA再去查看时，已经错过了最佳的事故处理时机。所以，我们要在故障发生之后，制定一些应对策略，例如快速切换主库、自动屏蔽下线问题从库等等。除此之外，还有一个比较难的问题，就是如何避免相似的故障再次出现。挑战二：人力和发展困境第二个挑战是人力和发展的困境，当服务流量成倍增长时，其成本并不是以相同的速度对应增长的。当业务逻辑越来越复杂时，每增加一块钱的营收，其后面对应的数据库QPS可能是2倍甚至5倍，业务逻辑越复杂，服务支撑的难度越大。另外，传统的关系型数据库在容量、延时、响应时间以及数据量等方面很容易达到瓶颈，这就需要我们不断拆分集群，同时开发诉求也多种多样，当我们尝试使用平台化的思想去解决问题时，还要充分思考如何满足研发人员多样化的需求。人力困境这一问题，从DBA的角度来说，时间被严重的碎片化，自身的成长就会遇到瓶颈，比如经常会做一些枯燥的重复操作；另外，业务咨询量暴增，尽管我们已经在尝试平台化的方法，但是还是跟不上业务发展的速度。还有一个就是专业的DBA越来越匮乏，越来越贵，关键是根本招聘不到人手。在这种背景下，我们必须去思考：如何突破困局？如何朝着智能化转型？传统运维苦在哪里？智能化运维又能解决哪些问题？首先从故障产生的原因来说，传统运维是故障触发，而智能运维是隐患驱动。换句话来说，智能运维不用报警，通过看报表就能知道可能要出事了，能够把故障消灭在“萌芽”阶段；第二，传统运维是被动接受，而智能运维是主动出击。但主动出击不一定是通过DBA去做，可能是系统或者机器人操作；第三，传统运维是由DBA发起和解决的，而智能运维是系统发起、RD自助；第四，传统运维属于“人肉救火”，而智能运维属于“智能决策执行”；最后一点，传统运维需要DBA亲临事故现场，而智能运维DBA只需要“隐身幕后”。从自动化到智能化那么，如何从半自动化过渡到自动化，进而发展到智能化运维呢？在这个过程中，我们会面临哪些痛点呢?我们的目标是为整个公司的业务系统提供高效、稳定、快速的存储服务，这也是DBA存在的价值。业务并不关心后面是MySQL还是NoSQL，只关心数据是否没丢，服务是否可用，出了问题之后多长时间能够恢复等等。所以我们尽可能做到把这些东西对开发人员透明化，提供稳定高效快速的服务。而站在公司的角度，就是在有限的资源下，提升效率，降低成本，尽可能长远地解决问题。上图是传统运维和智能运维的特点分析，左边属于传统运维，右边属于智能运维。传统运维在采集这一块做的不够，所以它没有太多的数据可供参考，其分析和预警能力是比较弱的。而智能运维刚好是反过来，重采集，很多功夫都在平时做了，包括分析、预警和执行，智能分析并推送关键报表。而我们的目标，是让智能运维中的“报警+分析+执行”的比重占据的越来越少。决策执行如何去做呢？我们都知道，预警重要但不紧急，但报警是紧急且重要的，如果你不能够及时去处理的话，事态可能会扩大，甚至会给公司带来直接的经济损失。预警通常代表我们已经定位了一个问题，它的决策思路是非常清晰的，可以使用基于规则或AI的方式去解决，相对难度更小一些。而报警依赖于现场的链路分析，变量多、路径长，所以决策难，间接导致任何决策的风险可能都变大。所以说我们的策略就是全面的采集数据，然后增多预警，率先实现预警发现和处理的智能化。就像我们既有步枪，也有手枪和刺刀，能远距离解决敌人的，就尽量不要短兵相接、肉搏上阵。数据采集，从数据库角度来说，我们产生的数据分成四块，Global Status、Variable，Processlist、InnoDB Status，Slow、Error、General Log和Binlog；从应用侧来说，包含端到端成功率、响应时间95线、99线、错误日志和吞吐量；从系统层面，支持秒级采样、操作系统各项指标；从变更侧来看，包含集群拓扑调整、在线DDL、DML变更、DB平台操作日志和应用端发布记录等等。数据分析，首先是围绕集群分析，接着是实例、库，最后是表，其中每个对象都可以在多项指标上同比和环比，具体对比项可参考上图。通过上面的步骤，我们基本可以获得数据库的画像，并且帮助我们从整体上做资源规划和服务治理。例如，有些集群实例数特别多且有继续增加的趋势，那么服务器需要scale up；读增加迅猛，读写比变大，那么应考虑存储KV化；利用率和分布情况会影响到服务器采购和预算制定；哪几类报警最多，就专项治理，各个击破。从局部来说，我们根据分析到的一些数据，可以做一个集群的健康体检，例如数据库的某些指标是否超标、如何做调整等等。数据库预警，通过分析去发现隐患，把报警转化为预警。上图是我们实际情况下的报警统计分析结果，其中主从延迟占比最大。假设load.1minPerCPU比较高，我们怎么去解决？那么，可能需要采购CPU单核性能更高的机器，而不是采用更多的核心。再比如说磁盘空间，当我们发现3T的磁盘空间普遍不够时，我们下次可以采购6T或更大空间的磁盘。针对空间预警问题，什么时候需要拆分集群？MySQL数据库里，拆分或迁移数据库，花费的时间可能会很久。所以需要评估当前集群，按目前的增长速度还能支撑多长时间，进而反推何时要开始拆分、扩容等操作。针对慢查询的预警问题，我们会统计红黑榜，上图是统计数据，也有利用率和出轨率的数据。假设这是一个金融事业群的数据库，假设有业务需要访问且是直连，那么这时就会产生几个问题：第一个，有没有数据所有者的授权；第二个，如果不通过服务化方式或者接口，发生故障时，它可能会导致整个金融的数据库挂，如何进行降级？所以，我们会去统计出轨率跟慢查询，如果某数据库正被以一种非法的方式访问，那么我们就会扫描出来，再去进行服务治理。从运维的层面来说，我们做了故障快速转移，包括自动生成配置文件，自动判断是否启用监控，切换后自动重写配置，以及从库可自动恢复上线等等。报警自动处理，目前来说大部分的处理工作还是基于规则，在大背景下拟定规则，触发之后，按照满足的前提条件触发动作，随着库的规则定义的逐渐完善和丰富，可以逐步解决很多简单的问题，这部分就不再需要人的参与。展望未来我们还会做一个故障诊断平台，类似于“扁鹊”，实现日志的采集、入库和分析，同时提供接口，供全链路的故障定位和分析、服务化治理。展望智能运维，应该是在自动化和智能化上交叠演进，在ABC（AI、Big Data、Cloud Computing）三个方向上深入融合。在数据库领域，NoSQL和SQL界限正变得模糊，软硬结合、存储计算分离架构也被越来越多的应用，智能运维正当其时，我们也面临更多新的挑战。我们的目标是，希望通过DB平台的不断建设加固，平台能自己发现问题，自动定位问题，并智能的解决问题。作者简介应钢，美团点评研究员，数据库专家。曾就职于百度、新浪、去哪儿网等，10年数据库自动化运维开发、数据库性能优化、大规模数据库集群技术保障和架构优化经验。精通主流的SQL与NoSQL系统，现专注于公司业务在NewSQL领域的创新和落地。

本文由Librant发表如果说在Linux环境下，什么编辑器最好用，如果我说是VIM，估计会有一大部分人嗤之以鼻，怎么可能。VIM可能是他用过众多编辑器最难用的一个。在我司用的是云虚拟机，说实话吧，这里吐槽一下，是真的卡，没开几个网页，打开几个软件就卡的不要不要的，后来码代码的时候，能用Linux机器我就尽量使用Linux环境，如果读者正好也是一名Gopher的话，那我就强烈建议你使用VIM，Vim-go是当前使用最为广泛的用于搭建Golang开发环境的vim插件。好了，废话不多说，看我搭建好的界面吧。图 Go-Vim界面看到这个界面，读者是不是不认识了，这就对了，是不是觉得很炫酷，其实Vim有很多的插件，可以把Vim打造的非常棒，等读者查阅相关资料，清楚Vim的各种参数的时候，就可以根据自己的喜好，搭建不同风格的Go开发环境啦。So废话不多说，开整。（建议先看完《跟我学Docker》的第一章部分）1.1 环境准备 能成功从gitHub拉取代码，Go编译器安装完成之后，就可以在搭建Go-Vim啦。首先是在当前用户的HOME目录下创建 .vim 目录和 .vimrc 文件：librant@ubuntu:$ mkdir .vimlibrant@ubuntu:$ touch .vimrc创建完成之后，进入到 .vim 中，下载插件 Vim 的插件管理器bundle：librant@ubuntu:/.vim$ mkdir bundle然后进入到 bundle 目录中，安装Vundle.vim：librant@ubuntu:/.vim/bundle$ git clone git clone https://github.com/VundleVim/…下载完成之后，会在当前目录下生成 Vundle.vim 目录同样进入到 bundle 目录中，安装Vim-go：librant@ubuntu:/.vim/bundle$ git clone https://github.com/fatih/vim-…下载完成之后，会在当前目录下生成 vim-go 目录1.2 插件安装/（用户$HOME） 目录下已经有 .vimrc文件就不需要再创建了。（" 为注释部分）。1.2.1 安装Vundle.vim在 .vimrc 文件中添加如下配置：set nocompatiblefiletype offset rtp+=~/.vim/bundle/Vundle.vimcall vundle#begin()Plugin ‘gmarik/Vundle.vim’call vundle#end()filetype plugin indent on保存后，退出。1.2.2 安装Vim-go继续编辑 .vimrc文件，在call vundle#begin()和call vundle#end()之间再添加如下配置：Plugin ‘fatih/vim-go’保存后，重新打开 vim 编辑器，在命令行的模式输入：PluginInstall:PluginInstall执行之后会在左侧出现需要安装的插件列表，右侧是.vimrc文件。如图1-2-2所示：图 1-2-2 Vim插件安装界面刚执行时，左下角会出现 Processing的过程，需要稍微等一会儿，这是在下载代码，安装完成之后，左下角将出现Done!的单词，表示已经安装完成。1.2.3 安装 go.tools Binaries Vim-go安装中需要使用到Go的相关的二进制工具。由于历史的原因，在google上的工具是无法自行下载安装的，在gitHub上的工具是可以安装成功的。首先打开 .vimrc 文件，切换到命令行模式，执行 GoInstallBinaries 命令自行安装。:GoInstallBinaries等待 Vim-go依赖的工具自动安装，如果安装成功后，会在 $GOPATH/bin 目录下生成。安装完成后如图1-2-3所示：图 1-3-2 vim-go依赖的命令文件由于有些命令文件是无法自动安装完成，这就需要手动进行安装啦。首先对比目录，看缺少哪些命令没有安装完成，然后去gitHub上搜索，找到对应的命令源码之后，使用git clone 下载到本地，然后使用 go install命令进行安装即可。前面已经讲解过如何安装啦，这里就不再赘述。相关工具的gitHub路径：golint: https://github.com/golang/lin...gocode: https://github.com/nsf/gocode...errcheck: https://github.com/kisielk/er...gotags: https://github.com/jstemmer/g...(缺少什么工具，基本都可以找到的，这里就不一一列举了)1.3 VIM主题颜色 Vim的主题颜色保存在 /usr/share/vim/vim80/colors 目录下保存，如果目录下没有的主题，就需要自己进行下载了。下载到此目录的颜色主题，将可以被所有用户使用，如果只需要在当前用户下使用，可以将下载的主题放在 /.vim/colors 目录下即可。个人比较喜欢molokai主题风格，下面就简单介绍如何下载这个主题吧。 1）在gitHub上搜索 molokai 主题，找到主题的git仓库 tomasr/molokai 2）进入到 .vim目录下，使用git clone 下载主题librant@ubuntu:/.vim$ git clone https://github.com/tomasr/mol… 3）下载完成之后，拷贝 molokai/colors/molokai.vim 文件到 ~/.vim/colors 目录下 4）配置 .vimrc 文件，在文件中红添加如下信息：set t_Co=256colorscheme molokailet g:molokai_original = 1let g:rehash256 = 1需要配置其他的主题，只需要设置相应的主题名称。1.4 其他插件安装1.4.1 SirVer/ultisnips UltiSnips是Vim的代码片段工具，它只是一个引擎，它需要和vim-snippets搭配使用。vim-snippets预定义了几十种语言常用的代码模板，位于 ~/.vim/bundle/vim-snippets/UltiSnips/，UltiSnips 有一套自己的代码模板语法规则。在 .vimrc中的配置如下：Plugin ‘honza/vim-snippets’Plugin ‘SirVer/ultisnips’“插入模式下直接通过<C-z>键来触发UltiSnips的代码块补全let g:UltiSnipsExpandTrigger="<C-z>““弹出UltiSnips的可用列表,由于不常用, 所以这里设置成了特殊的<C-i>映射let g:UltiSnipsListSnippets="<C-i>”"<C-f>跳转的到下一个代码块可编辑区let g:UltiSnipsJumpForwardTrigger="<C-f>”"<C-b>跳转到上一个代码块可编辑区let g:UltiSnipsJumpBackwardTrigger="<C-b>“增加位置如Go-vim的位置一致，安装过程也是类似的。gitHub的代码路径如下所示：honza/vim-snippets: https://github.com/honza/vim-...SirVer/ultisnips: https://github.com/SirVer/ult...1.4.2 scrooloose/nerdtree NERDTree的作用就是列出当前路径的目录树，一般IDE都是有的。可以方便的浏览项目的总体的目录结构和创建删除重命名文件或文件名。 在 .vimrc中的配置如下：Plugin ‘scrooloose/nerdtree’” 设置NerdTreemap <F7> :NERDTreeMirror<CR>map <F7> :NERDTreeToggle<CR>进入到 vim 后可以按 F7 显示和隐藏 NERDTree区域。gitHub的代码路径如下所示：scrooloose/nerdtree: https://github.com/scrooloose...1.4.3 majutsushi/tagbar tagbar可以将正在编辑的文件生成一个大纲视图，包含接口/方法/变量等, 可以选中快速跳转到目标位置, 编辑大文件特别有用。由于tagbar是基于ctags，需要先安装ctags：root@ubuntu:/# apt-get install ctags 在 .vimrc中的配置如下：“F9触发，设置宽度为30let g:tagbar_width = 30nmap <F9> :TagbarToggle<CR>“开启自动预览(随着光标在标签上的移动，顶部会出现一个实时的预览窗口)let g:tagbar_autopreview = 1"关闭排序,即按标签本身在文件中的位置排序let g:tagbar_sort = 0进入到 vim 后可以按 F9 开启和关闭tagbar功能 。gitHub的代码路径如下所示：majutsushi/tagbar: https://github.com/majutsushi...1.4.4 Raimondi/delimitMate delimitMate是自动补全引号(单引号/双引号/反引号), 括号(()[]{})的插件。 在 .vimrc中的配置如下：Plugin ‘Raimondi/delimitMate’gitHub的代码路径如下所示：Raimondi/delimitMate: https://github.com/Raimondi/d...GO语言调试利器——dlvvim创建程序文件自动添加头部注释附录：VIM参数设置解析set nocompatible：不要使用vi的键盘模式，而是vim自己的set number：显示行号set showcmd：输入的命令显示出来syntax on：开启语法高亮filetype on：检测文件类型 ...