9482

点击下载完整版PPT《华为云DevCloud大咖分享汇总（附PPT下载）》

点击下载PPT完整版《华为云DevCloud大咖分享汇总（附PPT下载）》【热门活动】寻找超级算法大师-挑战最优算法，赢取荣耀8X！跳转链接：https://bbs.huaweicloud.com/forum/thread-13282-1-1.html

想了解云计算领域的前沿技术和发展趋势？想得到最新华为云计算专家大咖的最新观点？为了满足大家的要求，本版主汇总了近期华为大咖的一些分享材料，供大家参考：1、文章标题：华为大咖分享：华为敏捷项目管理实践文章地址：http://forum.huaweicloud.com/forum.php?mod=viewthread&tid=1761&extra=page%3D32、文章标题：华为大咖分享：AI在软件测试领域应用探索文章地址：https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=1757&extra=page%3D13、文章标题：华为大咖分享：微服务架构设计与实践文章地址：https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=1762&extra=page%3D14、文章标题：华为大咖分享：拥抱Git,提升研发效率文章地址：https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=5004&extra=page%3D15、文章标题：游戏企业转型之道：敏捷与DevOps实践文章地址：https://bbs.huaweicloud.com/forum/thread-5819-1-1.html7、文章标题：华为大咖分享：基于容器的Devops文章地址：https://bbs.huaweicloud.com/forum/thread-5821-1-1.html8、文章标题：华为大咖分享：华为专家揭秘研发效能提升之道/DevCloud研发实践文章地址：https://bbs.huaweicloud.com/forum/thread-7130-1-1.html9、文章标题：华为大咖分享：DevOps敏捷测试之道文章地址：https://bbs.huaweicloud.com/forum/thread-11912-1-1.html10、文章标题：华为大咖分享：关于DevOps，听听华为专家怎么说文章地址：https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=12522&page=1&extra=#pid4050611、文章标题：华为大咖分享：交付在云端-全云DevOps研发实践文章地址：https://bbs.huaweicloud.com/forum/thread-12609-1-1.html12、文章标题：五星级软件工程师的高效秘诀文章地址：https://bbs.huaweicloud.com/forum/thread-12639-1-1.html13、文章标题：DevCloud on DevCloud 从1月1次到1天10次发布的实践分享文章地址：https://bbs.huaweicloud.com/forum/thread-12649-1-1.html14、文章标题：华为微服务转型DevOps实践文章地址：https://bbs.huaweicloud.com/forum/thread-12653-1-1.html15、文章标题：华为大咖分享：大型云平台的DevOps实践文章地址：https://bbs.huaweicloud.com/forum/thread-12720-1-1.html16、文章标题：华为大咖分享：大型云平台的DevOps实践文章地址：https://bbs.huaweicloud.com/forum/thread-12721-1-1.html17、文章标题：云上开发，代码托管只是第一步文章地址：https://bbs.huaweicloud.com/forum/thread-12722-1-1.html18、文章标题：反脆弱，高效能组织的能力构建文章地址：https://bbs.huaweicloud.com/forum/thread-12723-1-1.html19、文章标题：从Change、merge到New Challenge--华为内源平台到研发云平台的发展历程文章地址：https://bbs.huaweicloud.com/forum/thread-12724-1-1.html20、华为大咖分享：【HC2018 Session】基于Pipeline的DevOps核心实践_DevCloud_华为云论坛 (huaweicloud.com)21、华为大咖分享：Gopher China2020 华为云的go语言云原生实战经验（后附PPT下载）22、华为大咖分享：德智体美劳全面发展的DevOps_DevCloud_华为云论坛 (后附PPT下载)23、华为大咖分享：如何让团队在高度共识中完成需求沟通与设计（后附PPT下载）24、华为大咖分享：华为云DevCloud——云测API全场景测试技术与实践（后附PPT下载）25、华为大咖分享：华为敏捷与DevOps实践分享（后附PPT下载）

本帖最后由 写代码的贺大师 于 2017-11-29 14:29 编辑命令功能说明线上查询及帮助命令 (2 个)man查看命令帮助，命令的词典，更复杂的还有 info，但不常用。help查看 Linux 内置命令的帮助，比如 cd 命令。—help 也可以使用文件和目录操作命令 (18 个)ls全拼 list，功能是列出目录的内容及其内容属性信息。常用的是 llcd全拼 change directory，功能是从当前工作目录切换到指定的工作目录。cp全拼 copy，其功能为复制文件或目录。find查找的意思，用于查找目录及目录下的文件。mkdir全拼 make directories，其功能是创建目录。mv全拼 move，其功能是移动或重命名文件。pwd全拼 print working directory，其功能是显示当前工作目录的绝对路径。rename用于重命名文件。rm全拼 remove，其功能是删除一个或多个文件或目录。rmdir全拼 remove empty directories，功能是删除空目录。touch创建新的空文件，改变已有文件的时间戳属性。tree功能是以树形结构显示目录下的内容。basename显示文件名或目录名。dirname显示文件或目录路径。chattr改变文件的扩展属性。lsattr查看文件扩展属性。file显示文件的类型。md5sum计算和校验文件的 MD5 值。查看文件及内容处理命令（21 个）cat全拼 concatenate，功能是用于连接多个文件并且打印到屏幕输出或重定向到指定文件中。tactac 是 cat 的反向拼写，因此命令的功能为反向显示文件内容。more分页显示文件内容。less分页显示文件内容，more 命令的相反用法。head显示文件内容的头部。tail显示文件内容的尾部。常用的是tail -f动态显示文件追加的内容cut将文件的每一行按指定分隔符分割并输出。split分割文件为不同的小片段。paste按行合并文件内容。sort对文件的文本内容排序。uniq去除重复行。oldboywc统计文件的行数、单词数或字节数。iconv转换文件的编码格式。dos2unix将 DOS 格式文件转换成 UNIX 格式。diff全拼 difference，比较文件的差异，常用于文本文件。vimdiff命令行可视化文件比较工具，常用于文本文件。rev反向输出文件内容。grep/egrep过滤字符串，三剑客老三。join按两个文件的相同字段合并。tr替换或删除字符。vi/vim命令行文本编辑器。文件压缩及解压缩命令（4 个）tar打包压缩。oldboyunzip解压文件。gzipgzip 压缩工具。zip压缩工具。信息显示命令（11 个）uname显示操作系统相关信息的命令。hostname显示或者设置当前系统的主机名。dmesg显示开机信息，用于诊断系统故障。uptime显示系统运行时间及负载。stat显示文件或文件系统的状态。du计算磁盘空间使用情况。df报告文件系统磁盘空间的使用情况。top实时显示系统资源使用情况。free查看系统内存。date显示与设置系统时间。cal查看日历等时间信息。搜索文件命令（4 个）which查找二进制命令，按环境变量 PATH 路径查找。find从磁盘遍历查找文件或目录。whereis查找二进制命令，按环境变量 PATH 路径查找。locate从数据库 (/var/lib/mlocate/mlocate.db) 查找命令，使用 updatedb 更新库。用户管理命令（10 个）useradd添加用户。usermod修改系统已经存在的用户属性。userdel删除用户。groupadd添加用户组。passwd修改用户密码。chage修改用户密码有效期限。id查看用户的 uid,gid 及归属的用户组。su切换用户身份。visudo编辑 / etc/sudoers 文件的专属命令。sudo以另外一个用户身份（默认 root 用户）执行事先在 sudoers 文件允许的命令。基础网络操作命令（11 个）telnet使用 TELNET 协议远程登录。ssh使用 SSH 加密协议远程登录。scp全拼 secure copy，用于不同主机之间复制文件。wget命令行下载文件。ping测试主机之间网络的连通性。route显示和设置 linux 系统的路由表。ifconfig查看、配置、启用或禁用网络接口的命令。ifup启动网卡。ifdown关闭网卡。netstat查看网络状态。ss查看网络状态。深入网络操作命令（9 个）nmap网络扫描命令。lsof全名 list open files，也就是列举系统中已经被打开的文件。mail发送和接收邮件。mutt邮件管理命令。nslookup交互式查询互联网 DNS 服务器的命令。dig查找 DNS 解析过程。host查询 DNS 的命令。traceroute追踪数据传输路由状况。tcpdump命令行的抓包工具。有关磁盘与文件系统的命令（16 个）mount挂载文件系统。umount卸载文件系统。fsck检查并修复 Linux 文件系统。dd转换或复制文件。dumpe2fs导出 ext2/ext3/ext4 文件系统信息。dumpext2/3/4 文件系统备份工具。fdisk磁盘分区命令，适用于 2TB 以下磁盘分区。parted磁盘分区命令，没有磁盘大小限制，常用于 2TB 以下磁盘分区。mkfs格式化创建 Linux 文件系统。partprobe更新内核的硬盘分区表信息。e2fsck检查 ext2/ext3/ext4 类型文件系统。mkswap创建 Linux 交换分区。swapon启用交换分区。swapoff关闭交换分区。sync将内存缓冲区内的数据写入磁盘。resize2fs调整 ext2/ext3/ext4 文件系统大小。系统权限及用户授权相关命令（4 个）chmod改变文件或目录权限。chown改变文件或目录的属主和属组。chgrp更改文件用户组。umask显示或设置权限掩码。查看系统用户登陆信息的命令（7 个）whoami显示当前有效的用户名称，相当于执行 id -un 命令。who显示目前登录系统的用户信息。w显示已经登陆系统的用户列表，并显示用户正在执行的指令。last显示登入系统的用户。lastlog显示系统中所有用户最近一次登录信息。users显示当前登录系统的所有用户的用户列表。finger查找并显示用户信息。内置命令及其它（19 个）echo打印变量，或直接输出指定的字符串printf将结果格式化输出到标准输出。rpm管理 rpm 包的命令。yum自动化简单化地管理 rpm 包的命令。watch周期性的执行给定的命令，并将命令的输出以全屏方式显示。alias设置系统别名。unalias取消系统别名。date查看或设置系统时间。clear清除屏幕，简称清屏。history查看命令执行的历史纪录。eject弹出光驱。time计算命令执行时间。nc功能强大的网络工具。xargs将标准输入转换成命令行参数。exec调用并执行指令的命令。export设置或者显示环境变量。unset删除变量或函数。type用于判断另外一个命令是否是内置命令。bc命令行科学计算器系统管理与性能监视命令 (9 个)chkconfig管理 Linux 系统开机启动项。vmstat虚拟内存统计。mpstat显示各个可用 CPU 的状态统计。iostat统计系统 IO。sar全面地获取系统的 CPU、运行队列、磁盘 I/O、分页（交换区）、内存、 CPU 中断和网络等性能数据。ipcs用于报告 Linux 中进程间通信设施的状态，显示的信息包括消息列表、共享内存和信号量的信息。ipcrm用来删除一个或更多的消息队列、信号量集或者共享内存标识。strace用于诊断、调试 Linux 用户空间跟踪器。我们用它来监控用户空间进程和内核的交互，比如系统调用、信号传递、进程状态变更等。ltrace命令会跟踪进程的库函数调用, 它会显现出哪个库函数被调用。关机 / 重启 / 注销和查看系统信息的命令（6 个）shutdown关机。halt关机。poweroff关闭电源。logout退出当前登录的 Shell。exit退出当前登录的 Shell。Ctrl+d退出当前登录的 Shell 的快捷键。进程管理相关命令（15 个）bg将一个在后台暂停的命令，变成继续执行 （在后台执行）。fg将后台中的命令调至前台继续运行。jobs查看当前有多少在后台运行的命令。kill终止进程。killall通过进程名终止进程。pkill通过进程名终止进程。crontab定时任务命令。ps显示进程的快照。pstree树形显示进程。nice/renice调整程序运行的优先级。nohup忽略挂起信号运行指定的命令。 也可以使用screenpgrep查找匹配条件的进程。runlevel查看系统当前运行级别。init切换运行级别。service启动、停止、重新启动和关闭系统服务，还可以显示所有系统服务的当前状态。

本帖最后由 DevCloud 于 2017-9-22 14:42 编辑页数比较多， 给大家截了几张图，想看完整版的可以去下载，下载地址在帖子最后面： 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 PDF下载地址： [hide]云盘地址： 链接: https://pan.baidu.com/s/1c30qJG 密码: 7u92[/hide]

本文包含作者从网上获得的DevOps超全的学习资料和工具集等，分享来自百度网盘，原分享者表示来自【高效运维社区】，向【高效运维社区】致敬。 663 664 665 666 下载地址：[hide]下载地址： https://pan.baidu.com/s/1jIQPI8Q 提取密码：42p2[/hide]

本帖最后由 HW Developer 于 2017-8-29 15:48 编辑“你在团队里是做什么的？” “DevOps。” “DevOps是什么呢？” “DevOps是一种文化、一种实践，目标是加快软件迭代速度，让团队更快交付价值。” “能不能具体点，你们日常工作的主要内容是什么？” “修Pipeline...” 作为一名开发，在刚涉足DevOps领域的时候，最难的就是和传统运维撇清关系；等到DevOps不再被当成是运维，又容易被当成是专职修Pipeline的人。 DevOps在一遍遍被人们提及、一次次在项目中被实践时，也在不断地被重新定义，DevOps是什么？这个问题可能到现在也比较难说清楚，但是项目中的“DevOps”做了些什么，却是清晰可见的。 本文就结合笔者的切身经历，谈一谈关于DevOps交付的价值以及在企业转型过程中遇到的一些问题。 背景介绍 客户是一家澳洲大型金融保险企业，其IT部门总人数在千人以上，维护应用两百余个。在经历了几年的收购和合并之后，在业务上指定了“将收购来的多个品牌进行整合”的大方针，于是IT部门也开始面临系统整合、业务线整合、网站合并的问题，同时客户正在将他们的服务逐渐从自建数据中心向AWS公有云服务上迁移。 团队概览 在数字化转型的漫漫长路中，该企业已经在内部搭建起了一套持续交付系统，以Jenkins为中心，有制品库、依赖管理、代码管理、任务管理系统，敏捷实践成熟。 我所在的团队是在整个组织向DevOps转型中的一个比较关键的团队，肩负着CI/CD优化、持续交付改进、运维能力输出的重任。类似的团队应该在很多DevOps转型的组织里都有，负责维护CI/CD基础设施、搭建应用开发脚手架、维护基础设施变更、做各种自动化的工作（姑且就将这类团队称之为Platform团队）。 比较特殊的是我在的这个团队实行轮岗制，由产品团队的成员（通常是开发人员）定期轮换到Platform团队，带着在产品团队遇到但是没能解决的问题，在这个团队中寻求最佳实践和解决方案，一段时间后（通常是三个月），开发人员从Platform团队回到开发团队，同时将DevOps技能和最佳实践带到产品开发团队。 整个Platform团队基本维持在3-5人的规模，有一个IM（Iteration Manager迭代经理），其余全是开发人员。 取得的成就 回顾过去的五个月，Platform团队一共经历了10个迭代（每个迭代两个星期），我梳理了一下每个迭代的工作内容，整理出主要成就如下： [*]围绕CI/CD做了很多优化，比如简化Jenkins slave创建流程、给自动化脚本（基础设施代码）贡献了许多新功能。 [*]新技术试点，比如尝试将静态文件部署到AWS S3中代替Apache服务。 [*]为应用设置监控，更新了基础设施脚本用于开启监控，并协助应用团队将配置脚本应用到各个环境。 [*]团队之间的沟通，了解开发团队痛点，帮助开发团队找到能够解决问题的团队（权限、责任划分、知识传递），技能培训等。 [*]响应变化，解决技术难题（虽然我认为这更像是一个沟通+权限的问题，但是其他所有团队都认为是技术难题，那我也就这样认为吧），以及修复一些类似于硬盘空间已满、网络延迟、权限的问题。 遇到的问题 当然在交付价值的同时，有很多痛点是非常折磨人的： [*]权限分配：作为一个跨开发团队工作的团队，不但没有拥有比开发团队更多的权限，甚至连开发团队的一些权限都没有，比如不能向开发团队的代码库提交代码(修改基础设施代码需要这个权限)，比如缺少Linux权限导致服务器底层问题没法直接修复，再比如 Jenkins 的问题追踪到了服务层需要维护Jenkins的团队支持，因为涉及到CI／CD的应用是由别的团队在管理。 [*]沟通效率：为了解决一个bug，有时候要花上两周的时间发邮件，找关键人物，组织会议，跟不同的人解释五遍以上的上下文（技术细节的上下文是很繁琐的），最后解决问题的人还很有可能不是自己团队的（没有权限）。因为大家平时都很忙，而且建卡工作的方式让一部分人对团队请求帮助的问题不是很热心，这种情况在沟通的时候如果表现得情商不够高，对方就会要你发邮件给他们团队然后等 IM 建卡，规划到迭代里再说了，我遇到过一次这样的情况，最后还是通过社工手段拿下了这个关键人物，过程不可谓不曲折。 [*]明确需求：Platform团队并不交付业务价值，因此没有BA(Business **yst业务分析师，通常扮演梳理需求的角色)，建卡的事基本都由IM和Dev来做，虽然感觉上是合理的，但实施起来却遇到很多问题，究其根本就是对需求的定义和划分不够明确，导致最后挪卡的时候大家都说不准这张卡算不算完成了，只能用拍脑袋的方式来决定。 [*]质量分析：同上，团队缺少QA(Quality Assurance，质量工程师，测试人员)，Dev们都是自己做卡自己测，有时候会结对测试，但也会因为对需求理解不充分，或者说拆卡拆得有问题，导致一些卡完成得质量不够，直接影响受依赖的卡。举个例子，部署监控需要自动化脚本的两个模块支持，两个模块被分为两张卡，在做第一张卡的时候遇到了诸多问题，好不容易把代码提交到别人的版本库里了，在做第二张卡的时候却发现第一张卡代码里多写了一对引号，导致整个逻辑实现失败，这个时候再回过头来改之前的代码，又要重新解决之前遇到的各种问题（沟通、权限，PS：这个时候做第一张卡的人还下了项目），周期和浪费的工时是可想而知的。 [*]人员轮岗：这是 IM 一直很头疼的一件事，Platform团队大量的时间花在给新来的团队成员输入上下文、同时又有成员离开团队要交接工作、尤其在沟通重要的工作中，成员的离开意味着需要新的人重新和干系人建立联系，再者，一些成员因为项目上的痛点，不是很有心思工作在团队的事务上，而是更关心自己过段时间会被分配到那个团队，如此种种都对团队的价值交付造成了很大的困扰。举一个例子，有一个端到端测试工具一直由Platform团队维护，从我加入Platform团队开始，这个测试工具就打算新增一个集成远程浏览器引擎的功能，这是一个非常有价值的功能，因为开发团队长期苦于浏览器版本支持过少，端到端测试不稳定；但是在实现过程中一直存在一个网络问题，这张卡先后被关闭、开启、标记完成、又重新开启，经历了大概五六个人的手，困扰我们的网络问题直到Platform团队解散，都没能解决。 [*]关键角色管理：做了什么很重要，有时候让别人知道你做了什么比做了什么更重要。这一点在 Platform 团队体现的得尤为明显；在交付团队中，开发如果发现资源不足，需要和TL(Tech Lead 或是Team Lead，可以理解为项目组长)或者PM(Production Manager 产品经理)沟通，如果缺少合适的汇报对象，一方面在团队需要外部支持或更多资源（比如权限）的时候得不到及时的支持，另一方面意味着团队缺少了更高的视角来实时回顾自己做的事情是否是正确的，方向有没有走偏，或者是不是又在造别人造过的轮子。我在团队解散后的回顾会议中，IM还坚持认为我们团队被解散是因为没有一个强有力的领导在背后支持，这也从侧面反映了我们没有找到合适的汇报人，告诉他，我们在做什么，听他说，我们下一步可以做什么。 分析 问题背后的原因及可能的改进方案 团队解散后经过一段时间的沉淀，我针对以上痛点与过往的成员一一交谈，了解了他们的想法，总结分析出了以下原因，以及可能的解决方案。 原因1：团队方向不清晰 不同于交付业务价值的产品团队，Platform团队不对某一个具体的产品负责，也不直接产出业务价值，加上Platform团队对交付的价值缺乏有效的指标度量，造成了团队方向不清晰的状况。 可能的改进方案：Platform 团队应该是属于架构师的一个机动团队，在团队方向不清晰的时候应该立即与利益相关者(Stakeholder)沟通，即与架构师取得联系，取得高视角的资源，最好能建立交付价值指标，比如Platform团队的目标是加快持续交付，提高交付质量，那就可视化开发团队发布周期、质量报告，让每个团队成员看到Platform团队交付价值的体现，从而明确团队方向。 原因2：团队角色缺失 在架构师不能全权参与团队工作的情况下（甚至Platform团队还可能没有IM），一帮Dev就很容易失去对团队整体的感知，每个Dev只关心自己手里的工作，迭代开始初期容易考虑不到全局影响、不能准确建卡，迭代进行时因为没有合适的汇报人因而跨团队交流困难，迭代结束时没有优质的回顾。 在Micromanagement Culture（微观管理文化）中有一个Alignment(校准)和Autonomy(自治)两个互斥的指标，我们使用这两个指标作为向量构成四个象限，如下图所示： 高校准、低自治的团队由领导决定做什么以及怎么做，团队只需要执行，这样会形成“领导说什么就是什么”的局面； [*] 而高校准且高自治的团队是由领导指出要解决的问题以及原因，然后由团队成员相互合作共同找到问题的解决方案； [*]低校准、低自治的团队则缺乏活力，只能循规蹈矩； [*]而高自治、低校准的团队成员可以做任何他们想做的事情，领导则很无助因为没有人关心真正需要解决的问题。 在敏捷团队中，如果团队成员只剩下Dev，情形则很有可能变成图中左下象限（也有些许右下）的情况，要想达到右上象限的期望状态，需要提高自治，更多的是校准。 可能的改进方案：在意识到这个问题的时候，团队需要一个关键人物出面充当领导者的角色，扮演这个角色的人必须关注团队交付价值、目标和方向，并且有强大的沟通能力让团队成员目标一致；和利益相关者加强沟通，保证团队方向不会跑偏。 高校准、低自治的团队由领导决定做什么以及怎么做，团队只需要执行，这样会形成“领导说什么就是什么”的局面； [*]而高校准且高自治的团队是由领导指出要解决的问题以及原因，然后由团队成员相互合作共同找到问题的解决方案； [*]低校准、低自治的团队则缺乏活力，只能循规蹈矩； [*]而高自治、低校准的团队成员可以做任何他们想做的事情，领导则很无助因为没有人关心真正需要解决的问题。 在敏捷团队中，如果团队成员只剩下Dev，情形则很有可能变成图中左下象限（也有些许右下）的情况，要想达到右上象限的期望状态，需要提高自治，更多的是校准。 可能的改进方案：在意识到这个问题的时候，团队需要一个关键人物出面充当领导者的角色，扮演这个角色的人必须关注团队交付价值、目标和方向，并且有强大的沟通能力让团队成员目标一致；和利益相关者加强沟通，保证团队方向不会跑偏。 根本原因 Platform团队成立初期被定义为一个立意高远（DevOps转型）的组织，但是在项目实施过程中变得越来越边缘化，其中有“人”的原因，有组织架构的原因，当然还有一些客观原因。但我突然意识到这背后有一个原因一直忽视了，那就是——我们在实践DevOps反模式。 国内近年来一直在对DevOps如何落地争论不休，DevOps提倡的是打破开发和运维的部门墙，将开发和运维（的能力）放在一个团队。然而国内大部分项目的现状是，开发不具备运维技能和意识，也不愿意做“背锅侠”（要求开发做运维一定程度上牺牲了开发的利益，比如亚马逊的开发每隔一周会被要求24小时On-call）。 因此一些公司选择了在项目中先成立一个 “DevOps团队” 作为过渡，再慢慢将CI/CD的理念和技能扩散到其他团队，但是这种方式稍不注意就会变成“换了个名字的Ops ”，因为工作内容相似，写脚本、做高可用，这些是传统运维也会做的事情，这种形式非常不利于团队思维的转变，“团队整体对最终交付物负责”才是DevOps的精要，而不是把团队按职责划分（只对流程负责）。 这样的要求无异是给项目成员增加了工作量和责任，对他们提出了更高的要求。然而很多职员不愿意无回报地多背负一些责任，比如说开发，谁不愿意每天写点代码一提交就早早回家，DevOps要求他们得看着新功能上线，确保无误之后才能离开；所以DevOps的推行在产品团队中是有阻力的，因此DevOps的成功不光需要团队内部努力，也需要得到高层支持并扫除障碍。 反思 [*]尽早找到关键角色，并且管理好利益相关人。这一点在一个扁平化组织里往往是最容易被忽视的，在意识到要和 Stackholders(利益相关者)建立联系之前，Platform 团队走了很多弯路，也错失了很多机会。 [*]让事情发生比如何发生更重要。应该说在这5个月的工作中，我认为最有价值的是最后两个迭代开始真正搜集来自应用团队的需求，开始在两地组织各个团队的 TL 开会搜集痛点和解决方案。作为 Platform 团队的一员，这件事其实我早就意识到会是非常有价值的，但始终没有去做，总是顾虑不知道怎么去开始、去推动，担心TL 们提出的问题不能得到真正解决。但是最后这件事终于发生了，才意识到真的是非常有价值，而且早该这么做了。 我们是否还需要DevOps团队 结合我自身的经历，“DevOps 团队”应该是一次有价值的试错，让我看到了这种方式的一些弊端，应用开发团队自身如果不具备产品思维，要由一个**的团队去影响它们是很难的，这种实践下的 DevOps 团队就像是披着 DevOps 外衣的 Ops 团队，不能产生理想的价值。 相比之下如果有一种自上而下的方式让开发团队基于已有业务基础之上去优化交付流程，并对每一个提交的最终价值负责，将产品思维真正植入到开发团队，从而达到全局优化的效果，这种做法才更符合真正的 DevOps 精神。线，确保无误之后才能离开；所以DevOps的推行在产品团队中是有阻力的，因此DevOps的成功不光需要团队内部努力，也需要得到高层支持并扫除障碍。

本帖最后由 DevCloud 于 2017-9-22 14:42 编辑2017年度DevOps现状调查报告中文翻译完整版可以download了，附件中有地址和密码！ 满满50多页，全部翻译成中文了！DevOps时代和高效运维社区第一时间组织国内知名公司的多位DevOps领域专家共同完成翻译，更有多位行业专家倾情推荐。 我们希望借此促进DevOps在国内的进一步应用和推广，帮助大家实现DevOps转型和落地，成就更多的高效能组织。 报告亮点[indent] [*]变革型领导者有五大共同特征，这些特征对塑造组织的文化和实践，提高组织效能影响巨大 [*]高效能团队在产品快速迭代和稳定性上可以兼得 [*]自动化是组织的法宝 [*]DevOps适用于所有组织 [*]松散耦合的架构和团队是持续交付最有力的预测指标 [*]精益产品管理推动组织效率提升 [/indent]变革领导力491 我们正处在DevOps转型与落地的时代，变革领导力对于组织的DevOps转型至关重要。 [indent] [*]愿景：对组织走向有明确的概念，五年后应该达到的目标很清晰。 [*]鼓舞型沟通： 采用一种鼓舞和激励的方式进行沟通，尤其是在一种不确定的环境中。 [*]智力激发：鼓励员工以全新的角度思考问题。 [*]支持型领导：设身处地地关注员工的个人需求和感受。 [*]个体认同：表彰目标达成和工作质量改进，亲自祝贺那些做出了杰出贡献的同僚。 [/indent]变更领导力和技术实践、精益产品管理、TI效能和组织效能的关系如下图： 492 变革型领导者授权和支持团队进行更多的尝试，帮助建立卓越的团队，卓越的技术和卓越的组织。 生产力和稳定性可以兼得今年的高效能组织相比去年，在生产力方面的优势缩小了，但是稳定性的优势更加明显。 493 调查报告显示低效能组织的生产力（部署频率和变更前置时间）有所提升，但是稳定性（故障恢复时间、变更失败率）下降了。原因在于在追求生产力的过程中，忽略了质量的建设。高效能组织通过内建质量和自动化降低了手工作业和返工，生产力和稳定性兼得。 494 报告中也明确指出中等效能组织因为处在转型期，正在积极消除技术债务，导致效能优势不明显，报告预测一旦经过了降低技术债务的阶段，进一步的自动化变得触手可及，团队在将迎来新的阶段。 报告指出除了企业，DevOps在非**机构和监管严格的行业中也应用广泛。可以说DevOps深深的影响着整个IT行业。 技术实践1. 持续交付在这几年的报告中，持续交付一直都是核心实践。优维科技王津银和高效运维社区张乐也多次提到持续交付是DevOps的核心工程实践。在EXIN DevOps Master认证知识体系中持续交付也是重要的一环。 495 持续交付可以帮助我们的团队的： [indent] [*]在整个软件交付生命周期中，团队可以按需部署到生产环境或终端用户。 [*]将系统质量和部署问题快速反馈给团队中的每个人，并且确保大家对此类问题高度重视并做出反应。 [/indent]影响持续交付的因素： 496 在持续交付中全面使用版本控制、持续集成和主干开发、在软件交付中集成安全机制、导入自动化测试和自动化部署都对IT效能有非常正面的影响。其中，自动化测试所带来的正向影响最为显著。 2. 松耦合架构康威定律是挥之不去的魔咒：“设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。”报告今年也重点关注了组织和系统的架构，在松散耦合的架构中，在不依赖关联组件或服务的变更下修改独立的组件或服务是非常容易的。就组织而言，当团队不需要依赖于其他团队就能完成他们的工作时，就可以称之为松耦合团队 报告中通过以下两种方式评估服务和组件之间的耦合性： [indent] [*]受访者可以脱离集成环境进行测试。 [*]应用程序可以独立于其所依赖的应用和服务进行部署或发布。 [/indent]松耦合架构对持续交付、质量和安全都非常重要： 497 主干开发代码配置管理是DevOps工程实践的起点，而分支策略更是起点的起点。主干开发基于主干进行代码提交和集成，英文Trunk Based Development（TBD）是大型互联网企业非常青睐的分支策略。 498 报告中明确说明主干开发的要求： [indent] [*]每天向主干合并一次代码 [*]让分支生命周期尽量短（少于一天） [*]同一时间少于三条的活跃分支 [/indent]高效能和低效能团队的分支策略差异十分明显： [indent] [*]高效能研发团队拥有最短的集成周期和分支存活时间，普遍持续若干小时 [*]低效能研发团队拥有最长的集成周期和分支存活时间，普遍持续数日 [/indent]精益产品管理从2016年开始，精益产品管理出现在DevOps年度现状调查报告中，行业普遍在应用精益产品管理方法和实践，比如：看板、小批量、MVP、授权开发团队等等。 精益大神何勉老师的精益看板体系就是非常落地的体系和实践，其中管理价值流动和建立反馈循环都是 DevOps 的核心目标。 499 DevOps与商业成品软件自从2009年DevOps出现以来，我们总能听到这样的声音：”我们的环境不适合DevOps，因为我们绝大多数使用的都是商业软件。“但事实证明，越来越多的传统企业都在尝试拥抱DevOps，选择架构合理的商业软件，减少定制化，DevOps与商业成品软件也能完美契合。 500 DevOps遍地开花从统计资料显示，DevOps 正在各个行业，各种规模的企业中落地，DevOps团队的比例 2014年16%，2015年19%，2016年22%，2017年已经增长到27%，越来越多的企业和团队开始拥抱 DevOps 501 结论报告的结论说，有一件事被证明一直是正确的：因为几乎每家公司都依赖于软件，IT效能成为每个组织的核心竞争力。IT效能会受到很多因素的影响，包括领导力，工具，自动化和持续学习与改进的文化。 [indent]文章来源：DevOps时代社区 2017年度 DevOps 现状调查报告中文完整版download地址：回复可见 [hide]链接: https://pan.baidu.com/s/1i546Z6P 密码: ptqr[/hide] [/indent]

本帖最后由 DevCloud 于 2017-9-22 16:15 编辑[flash]https://imgcache.qq.com/tencentvideo_v1/playerv3/TPout.swf?max_age=86400&v=20161117&vid=f05126eu7my&auto=0[/flash]