APP下载
报价宝 > 综合 >

超详细！DevOps2015热血青年Day1笔记大整理

消息来源:baojiabao.com 作者: 发布时间：2024-05-20

报价宝综合消息超详细！DevOps2015热血青年Day1笔记大整理
图片来源: 

林小草

作者：网络行动科技NETivim工程师郑富源 和“林小草的光影切片”网站，本文经作者授权转载。原文网站链接

会议内容不可以录音录影，所以这次就只有我的笔记啰。话说过程中因为太多我不懂的东西了，所以我好放空～所幸我在 facebook 打卡后，Gloom 学长浮出水面说他也在现场，我立刻回到大学模式，厚著脸皮端著电脑跑去找他吃饭聊天讲八卦兼要笔记，哇哈哈～

【开场致词：iThome 电脑报总编辑吴其勋】

总编喊了活动名称，我才发现原来 “DevOps” 的发音是 "Dave up"，我都分开念挖哈哈XD，而且总编说国外 DevOps 已经热了一段时间，我要不是因为这场活动我根本不知道这名词，妈妈对资讯业的脱节感好重。XD

总编致词提到传统布署的期程都以周与月来计算，南非有间银行导入 DevOps 前，每次布署约要四周时间，导入之后每次更新只要 17 分钟。好惊人的时间差距！“天下武功，惟快不破”，主席认为提升布署速度是有助于增加竞争力的。

一般会有“只有做网站的才需要 DevOps，一般企业没有导入 DevOps 必要”的迷思，总编也希望能够透过这个研讨会打破这样的概念，让大家可以从中互相交流对自己公司有助益的技术。

【DevOps 运动的全球大趋势：iThome 新闻主编王宏仁】

简报里以非洲最大标准银行 (Standard Bank) 为例，这间银行在南非是大型主机供应商眼中的大客户，营运上有采用新的前端技术、也有传统的后端操作系统平台。2014 年，他们先花两天时间让 35 位高层主管了解什么是 DevOps，了解导入的技术名词、可能造成的冲击，以降低未来导入时的阻力。

接着他们在导入时把一群人带进 war room，为导入 DevOps 的团队设计了上头印有 “chop chop” 的上衣。“chop chop” 在非洲土语有笨蛋的意味，在粤语里则有“快”的意思，在这个银行导入时，一方面自嘲导入这个技术像是笨蛋一样，另一方面也是互相督促要加速导入这个能够让开发流程更加快速的概念。

导入前，每次布署约需花三个月；成功导入后，每次布署只要 17 分钟。（备注：我觉得这边数据有问题，因为我算起来三个月并不是十七分钟的两千倍啊，总编提到的四周换算起来比较接近两千倍⋯⋯不过重点是大大地节省了两千倍的时间！）

〖相关连结〗

【CI 服务器全制霸！活用自动化技术重建“最强”团队：乐天公司旅游业务开发维运部 旅游网站团队经理直井和久】

在 2014 年乐天因为服务过多，造成无法正常让原有的 CI 运作，这个 talk 就是要讲这个问题的排除过程。讲者边讲也边鼓励大家，要去日本玩也可以使用乐天旅游服务噢。XD

一开始会想要做改变，是因为原有的 CI server 已过载，无法如期上线，且再增加新的 job 就会使得 CI server 整个挂掉，使得后续营运都无法正常运作。原有的 CI server 上有超过 400 个 job，只有一台 server 来处理，无人维护、监控⋯⋯总之是问题重重。为了不让客户流失，所以重组了团队来处理这些问题。先定义出问题与要监控的标的后，增加了四台 server 来处理 CI，将原来的 server 作为 master server，利用 docker 将 master & slave server 之间互相同步。使用 docker 的原因是对系统维运人员或开发者，docker 都很好上手。为了降低开发人员与维运人员之间的沟通落差，采用 chef。

未来要面对的问题：增加 UT (unit test) 涵盖率。

〖演讲后的 Q&A〗

  • Q: Roadmap 上有两段与原本规划落后甚远的，似乎如何让新手对新制度与工具上手就是最难的地方？有没有什么训练的技巧？ 

    A: 两三年经验的工程师对学习技术还算容易上手，但还是需要花个一两周时间来学会技巧，熟悉整个流程需要约一个月的时间。
  • Q: 前面有提到 Jenkins 很慢，那为何使用 Jenkins? 花多少时间做 test case？ 

    A: 选用 Jenkins 只是因为我们有成员希望用它XD。
  • Q: 如果 job 会与其他 sub-system 相依，在 CI 上怎么处理这个问题？ 

    A: 架一个 serer 来降低 API 的 loading。
  • Q: 如果 master server 的 Jenkins 挂了，要花多久时间复原？

    A: 环境放在 docker 里，所以下个指令就可以 recover，大约一小时左右就可以复原。

〖相关连结〗

【企业DevOps：Chef 全球传教士 Michael Ducy】

DevOps 始自 “10 deploys per day"。

搜寻 “DevOps” 可以找到一海票用这名词包装过的 solution、一海票相关的职缺，明明是 2009 才出现的名词但是却有人号称有十年以上的 DevOps 经验⋯⋯DevOps 应该是种文化、是种专业、是种行动 (movement)，而非单一的角色或职缺。导入 DevOps 是为了让组织变得更好，而非只能应用在新创公司 (start-ups) 或网站相关企业。

DevOps 应该是 CALMS 这五项要素的实践:

  • Culture: 鼓励学习、鼓励改善与犯错、让组织变得更好的文化
  • Automation
  • Lean: 采用精实原则持续改善
  • Measurement 
  • Sharing

采行 DevOps 时，要考虑 DevOps 的风险、成本与速度。演讲里提到的案例：Major Telco 导入 DevOps 之前，需要 4 周布署，现在只要两小时；当时周日没有维运人员 (op) 可以为顾客服务，现在则全年无休。

每天都在 release 时，要花多少时间在这些流程上？换句话说，浪费了多少时间？相对于 Muda（浪费），应该追求 Lean（精实），可以尝试来个 30 天挑战：

  • Time boxed project
  • Gives organizations chance to experiment
  • Eliminates old processes to prove new
  • Eliminates waste

DevOps Dojo：

  • Build a team of experts（成立专家小组）
  • Use those experts to tran other teams（由这些专家当种子，去带其他人）
  • Execute a 30 Day Challenge to prove the methods（执行 30 天挑战，透过实作验证做法是否正确）

这一场有提到可以利用一些工具来让工作上的资讯互动更好，除了熟悉的 GitHub，Ducy 也推荐Slack、Google Hangout 来作为工作上的资讯交换辅助。

 （备注：演讲里有提到 coaching kata 这个字眼，kata 好像也是日文来的，这个讲者对日文好有爱噢）

〖相关连结〗

【Yahoo的持续交付经验分享 (Continuous Delivery @Yahoo)：Yahoo 亚太区产品研发工程部资深工程师应百怡】

在开场之前，先问了现场一个问题：大家 release 的频率有多高？现场的从业人员大约都是每个月更新一次以下。通常我们交付 (deliver) 的目的是要交付出有价值之物，简报的开头先以一个夸张的例子为例：需求者希望能得到一张“久坐不累”的椅子，结果产品开发部门提供了一张让人根本不会想坐在上头的椅子（这样就不会久坐，当然也不会坐到累了XD）。在 Yahoo 内部的持续交付，是不由任何人为介入、完全自动化的。在导入 CD (Continuous Delivery) 之后，更新频率高了四倍、品质也未下滑。对所有人来说都有进化与好处：

  • Developer: 开始习惯先写测试
  • QA: 更知道测试时要 focus 在哪里
  • SE: release 成本变小，有更多时间可以做其他有价值的事
  • Product Owner: 专案可以更顺利的推展

想推动  CD，得先要塑造一个文化是让大家都觉得 CD 是一个正常的事，这也不是只有工程师一个人的事，而是整个组织都需要进来帮忙的，无论是 developer, QA, SE or PM。在初期大家不免会有抗拒的情绪。

导入 CD 需要有强而有力的主管来协助，否则同侪之间可能会有抗拒新的作业流程的状况。以 Yahoo 而言，Marissa Mayer 非常强硬的不允许任何 exception，所有专案都要进 CD；过去的手动测试也不用直接进 CD，应该转成自动化测试。

Yahoo 计划导入 CD 的期程仅两季，由于其内部使用的程式语言众多、server 也非常多，所以订定出一些大方向的规则要求所有专案共同遵从：

  • 所有定义的 build 要可重复 (repeatable)、可重新产制 (reproductive)，例如这个 build version 在同一台主机上重复做个十次也应该都产出一样的结果，哪天 server 挂了，在新机器上应该也要能够直接布署
  • 所有的 code 都要可追踪 (traceable)，可以看得出来异动了哪些内容
  • 所有的程式都要进版本控制 (version control)
  • 先停下手边的开发来做 CD (STOP development and Do it)
  • 初期让资深工程师来做，不让新人做 (Use Senior Engineers)

导入 CD 之前的 release 是通霄达旦的关在 war room 里等待上线，导入之后，即使是正在 release，看起来也无异于平常开发。Yahoo 有一种特殊的台灯，亮紫色就表示 build 有问题，亮黄灯表示正常无事。

〖演讲后的 Q&A〗

  • Q: 简报里有提到 SVN 换成 Git，原因是什么？ 

    A: 不确定决定的原因，但就自己是个开发者，感觉到的转至 Git 的好处是，分散式的控管变容易了，code review 也容易，要 folk branch 也容易。
  • Q: 如果不是高层强力推行的话，一般在 release 失败时，会有压力反扑要求停止 CD 导入，要怎么推？另外简报中提到测试，原本是以人工测试为主、unit test 为辅，后来转为以 unit test 为主，这个反转是怎么办到的？ 

    A: 追本溯源还是要 manager 来推。 XD 另外之前有推过 CI 但是因为只是 CTO 推动，所以还是会得到阻力，最终还是要最高领导者或真正能做决定的人来推行。至于测试，必须要让工程师自己感受到 unit test 的自动化带来的好处，才能够从根本取代掉人工测试，最初是先把几个重要的 test case 先转成自动化。
  • Q: 金融系统会把网段切成两块，分成测试与正式，不知道 Yahoo 有没有类似的困境？ 

    A: 在一般网段会一路 push，到了特殊网段则会用 pulling 的方式，确定可更新才开始做后续的整合上线作业。
  • Q: 遇到阻力怎么办？ 

    A: 只要高阶被说服，通常就会成功了。阻力如果很多，就从肉粽的最上层开始解决吧，假设高层也很难说服，就先找一个不是那么至关紧要的先做 pilot，等到 pilot 成功了就可以拿来当案例说服长官了。 XD
  • Q: 四个 form 的 Jenkins 是互为 backup 吗？ 

    A: 因为有专门的 tools team 在管理，所以细节开发人员这边不是很清楚。
  • Q: 不同部门之间想法可能各异，如何交流？ 

    A: 比方说，有些 QA team 可能没有写测试的习惯，可能就是与他们分享自动化测试的好处，让他们了解自动化测试就可以不用在 release 当日待到那么晚。

【在公众云里建构SaaS的DevOps经验分享：趋势科技资深工程师陈彦宏】

这场要分享的是移植 2PB、约十亿支的档案的大量资料到公有云 (public cloud) 的经验。这个案子由两个 RD、两个 QA、两个 OP 来协同作业，将资料布署到 AWS 上。在趋势的 DC (data center) 的架构里有用到 MySQL, Mamcahed, MogileFS，这些东西就以 Amazon 相关的服务来替代，例如 MogileFS 就用 Amazon S3 来取代。

但是在 AWS 上，和传统的资料异动不同，像要改某个档案里的 100bytes 的资料，以前只要开档、存档就可以了，在 AWS 上可能得先把整个 project 下载下来，改好以后再整包丢上去，所耗费的时间会变多、也必须在云上准备适当的空间以便未来做档案置换。一定要做消防演习，确保事件发生的时候 backup 是有用的。DR drill (Disaster recovery drill) 可以拿来验证系统可承受到什么程度的灾害。一台机器在云上开起来，如果没有做好适当的 security policy 设定，可能很快就被打进来了，所以可以的话就用两阶段认证、设定 IAM-role 等等，

〖演讲后的 Q&A〗

  • Q: 前面其他人都有提到文化与主事者的支持，在趋势是否也有什么特别的导入经验？

    A: 每个 project 都有很高的自由度，目前不是每个 projects 都要导入 DevOps，但是老板都开放大家自由选择想要用什么技术。
  • Q: 专案会由谁来主导？是由 developer 或是 infrastructure architect 来主导？ 

    A: 专案中有 project manager，开发者与架构师这两者之间不会有谁主导谁，彼此间是协作的关系。
  • Q: 2TB 的资料移至 AWS 花了多少时间？带宽大小多大？如何检查资料连续性？ 

    A: 带宽约 1GB（←备注：有点惊人，不确定有没有听错）；我们有做 database checksum 的确认，档案也有抽测。
  • Q: 在趋势，RD 本来就熟 infrastructure 的东西吗？

    A: 在导入的过程开始把资料慢慢带给他，或是在其他专案执行到特殊状况时就找他们来一起看。

 

【百人工研院云端 OS 团队如何落实 CI：双子星云端运算首席执行官符儒嘉】

从 Agile（敏捷开发） → CI（持续整合） → CD（持续交付），大家会越来越快接受新的典范，例如接受电话、电脑、手机、智能手机的整个过程，大家会越来越快速接受新技术。在 2001 年左右，scrum 出现了，大家接受 agile 这样的开发模式。以符首席执行官的经验，他们习惯以 trello 来做专案的追踪工具。他推荐使用 spiraTest，每个 build 的 result 都可以记录下来，test 有几个 pass、几个 failed 都可以被记住，这个工具的费用也不贵。

“DevOps is an evolution from Agile.” 上头的人 (senior manager) 要支持，也要保留学习的时间给底下的人，DevOps 的导入才能成功。

〖演讲后的 Q&A〗

  • Q: 做系统时，目前有很多硬件还是没办法模拟的，例如 switch 的品牌等等，不知道有没有什么自动化的测试资源可使用？

    A: 确实有些硬件设备在软件面无法模拟，仅能用 spec 来做测试，但又因为每个 vendor 不一定照 spec 做，还是要手动做测试。
  • Q: 有没有说服老板导入 DevOps 的技巧？ 

    A: 要有 KPI 吧！（笑）以前很多人会说系统厂开发是没办法用 agile development 的、只能用在网络业，但是现在 agile 也变成通案了。
  • Q: 从 SVN 转到 Git 有没有什么推荐的升级工具 (migrate tool) 或是 log 的转档机制？

    A: 刚好在这个导入是新专案，所以没有升级 (migration) 的疑虑，偶尔参考到原有专案的 code，还是回头去看 SVN 上的 log。

【Whoscall 的 Realtime Monitoring 经验分享 (How Realtime Monitoring Works in Whoscall)：Gogolook 架构师叶秉哲】

这一场演讲结束后讲者当日就在 facebook 的 DevOps Taiwan 社团公开了简报连结。

 

首先先提到有张 DevOps 相关工具元素周期表，是国外有人以元素周期表的概念整理了所有 DevOps 工具，不过 Gogolook 并没有神农尝百草的把全部都试过一次，这边主要是讲周期表最下面的监控工具，都是目前他们用得很流畅的，在此抛砖引玉。

在导入工具之前，首先遵照 PMBOK，为系统做风险清册。对 Whoscall 而言最严重的就是 APP 当机、服务或数据库停摆，影响较小的就是效能降低之类的，前者是一发生就要立马处理的。

Whoscall 的架构里有使用到 CDN, load balance 等。就像前面提到的，影响最大的风险 app crash & service outage，维运人员会监控它们是否正常、回应时间是否正常、有无 error 等。会使用 pingdom 来确认网站服务是否正常。如果有异常，会发 slack 出来通知维运人员。

数据库要监控有无正常 I/O，或是资料可否正常取得。MongoDB 只要安装 mongo 的 cloud manager，资料会被传回 mongo 网站，维运人员可以到网站上看维运的报表。如果需要 cluster 等级的升级，还有付费功能可以买。

程式的效能降低时，可以透过 AWS cloudwatch 来观察，不过没办法看到 memory space & disk space。加上有些记录不会长期留存，所以会先用 fluentd 捞出来，再转到 StatsD 里。

详细的 fluentd 说明可以参考另一为 gogolook 工程师曾书庭在 Taipei.py 的分享：

一样是曾书庭分享的 Gogolook 使用的工具，还有这个《使用 Elasticsearch 及 Kibana 进行巨量资料搜寻及视觉化》：

把 raw data 转存到 StatsD 里后，可以搭配 Grafana 看报表。在 Java 里，可以使用 Metrics 来做资料的转换。相关的使用可以参考 Alan 在 JCConf 2014 的分享。

 Prometheus 是个多维度的时间序列数据库，可以做很多统计学家喜欢的复杂处理(slicing and dicing…etc.)，能比 cloudwatch & StatsD 更具弹性。 

〖演讲后的 Q&A〗

  • Q: 目前遇到的问题是工具太多、dash board 太多了，要四处看资料，有无其他辅助工具？

    A: 使用 Prometheus 就是为了解决这个问题。
  • Q: 在维运上成本与人力配置的状况？ 

    A: 成本部分因为不直接管钱所以不清楚，不过 BigQuery / EC2 都不贵；人的话，在 Gogoglook 每个人都有能力可以开发、写程式、监控、处理问题，真正专职做 OP 的人只有两个，其他 developer 都可以同时处理布署、监控等问题。
  • Q: 有监控到个别使用者吗？ 

    A: 要抓刻意做怪的使用者是靠 API 这边 log 使用者行为，再从 dash board 人工判断是否有异常的行为。
  • Q: 有没有 guidline 来要求工程师要写怎样的 log，以避免 GIGO（收到太多垃圾资料）？ 

    A: log 当然是多多益善，各个程式语言都有自己的 log library，问题在于工程师不会勤劳的写 log，通常都是遇到问题后回头检讨补上 log。
  • Q: 在 docker 上 monitor，应该从 container 监控还是主机比较好？

    A: 应该要看产品，像 Prometheus 有针对 docker 去做分析，所以可以从 container 去做分析。
  • Q: 即时监控对效能有影响，是所有监控都持续一直跑吗？还是特定期况才打开？ 

    A: 其实没有真正的 real-time，像金融业的 real-time 是以秒为单位、电信或导弹可能以毫秒为单位。real-time 产品的监控对系统造成的负担，是取决于监控的工具，越新的工具 overhead 越小。很少人看的报表就会在每季检讨后关掉。

〖其他补充资料〗

〖其他人的心得文〗

〖我自己的心得〗

  • 今天的重点关键字应该就是 docker、chef、Jenkins、slack 了，都没用过。XD
  • 这天议程最喜欢的就是最后一场 Gogolook 的监控心得分享，真的好想哪天去别人家公司待个几天，看看别人都怎么用工具、流程怎么走啊！
  • 其他议程强调文化的形塑，我觉得比较适合讲给高层听、或是企业内训的时候讲，这种顶多派一两个人出来上课的场合听到回去实在很难改变什么，只能默默把种子放心里了XD。其中有一场，好像是 Yahoo 的应百怡说的？该场讲者在 Q&A 时提到，高层是工程师上来的，就比较能接受新技术导入、愿意主导这样的文化。

 

2018-02-06 00:25:00
文章标签: 报价宝 降噪耳机价格 耳机价格 红米手机价格 华为手机价格 小米手机价格 电视机价格 笔记本电脑价格 笔记本价格 汽车价格 报价宝 笔记本价格 电视机价格 小米手机价格 红米手机价格

相关文章

最新资讯


手机


数码


科技

品牌选车

    选择品牌
    选择车系
    选择车型