专项话题►Shell企业级应用

Shell企业级应用

写在前面

本书还托管在看云，地址 https://www.kancloud.cn/djangowang/linux_bash_enterprise/2110024

开篇

欢迎阅读《Shell企业级应用》，笔者平日工作有些忙大部分是业余时间来整理，由于个人能力有限如有刊误请邮件8851970@qq.com谢谢。

为什么写这本书

最近在转型，从一名运维工程师转型到产品经理，做了多年的运维写了多年的程序总是在与机器打交道，如果把我做的事情比作程序语言，之前的工作经历更多的像程序中的常量没有变化，后续更多希望与人打交道而人更像变量，我想这也可以更多的丰富我的人生经历，所以在这个背景的基础上整理了《Shell企业级应用》这本书也是对过去的一个总结，在整理资料的过程中吃惊的发现多年前甚至在上学时整理的资料目前依然适用，重新整理其实也是重新学习它的过程，这里我也在想多年前的人是在什么基础上设计出了这么nb的系统直到目前依然适用且目前还看不到边际，我们从中学到的不应该是程序而是做事情的一些方法。

我在最早接触Shell编程时应该看得是《Shell编程第三版》这本书不过很早就已经绝版了,我看到的应该是印刷的版本这本书反复看了几次，随着时间推移每看一次都会有新的收获确实是一本不错的书除了这本书外还看过一本可口可乐公司系统管理员写的Bash在企业应用的书，另外就是网上当年Chinaunix.net一些热心人士整理的文章，推荐的网络版本书等，但是发现这些书大部分情况没有结构和连贯性，所以将这些书进行了汇总并由浅入深结合自己的工作经历和经验来介绍Bash学习过程，希望对大家能有帮助。

最后，这本书送给Bash设计者和曾经的参与者也送给自己还有那些懂得珍惜时间的人。
2018.11.3 by 研究僧 * 深圳南山科技园。

1.Shell编程基础

2.变量

3.Bash符号相关

4.内建命令与外部命令

5.read命令

6.条件语句

7.Bash循环&&分支语句

8.正则表达式

9.子Shell和受限Shell

10.函数与函数的加载

11.Bash脚本风格

12.Bash脚本调试

13.sed&&awk

14.awk

15Bash杂项&&案例

16.10.2.案例

多彩生活►旅拍&航拍

印度洋的明珠-斯里兰卡团建

本文目录结构

写在前面

一年一次的公司团建又开始了，我比往年参团要早些去年是9月今年是7月感觉像没过多久一样，其实也是正好内部成了民主团今年目的地就是标题的斯里兰卡，在没去斯里兰卡前我对他了解不是很多甚至成团后我还查了一下他的具体位置，有同事说如果要想看海又想看高山可以选择斯里兰卡也正因为这个我最终选择了斯里兰卡，以下介绍了斯里兰卡5天4晚的行程，整体分为三个部分：

  • 总结
  • 必备物品
  • 具体行程

总结

  1. 衣: 斯里兰卡虽然在热带，但是并没有想象那么热因为是一个岛国面朝大海有温度调节的作用，内陆地势又比较高相对比较凉爽。
  2. 食：很多同学说吃不惯当地食品，我个人觉得还可以当然旅游团也尽量帮我们安排了中餐，我看旅游行程中当地的导游吃的都是鸡肉、咖喱和手抓饭之类的，当然我们也会吃个人觉得适当换口味没有问题但估计如果长期居住在这就会有些不适应了。
  3. 住：整体行程旅店还是非常不错的，都有自己的游泳池和沙滩面朝印度洋非常不错，斯里兰卡是一个岛国，主要经济支柱靠旅游、农产品（茶）和港口贸易等所以旅游的设施如旅馆相对都还可以，但不能与国内旅馆比。
  4. 行：行程不是那么紧，每天早上9点出发，晚上8点到旅店，斯里兰卡如果自己去玩的话很多东西都可以忽略，但个人感觉那个海边火车、佛牙寺还是可以都值得体验一下的剩下的就是观海了因为他面朝印度洋且海浪很大适合冲浪。
  5. 文化：斯里兰卡是一个信仰比重人数较高的国家路上到处都是各种教堂与寺庙，你可以在这里了解当地的文化和背景，我还回来特意了解了一下印度教和佛教的一些区别，刷新了我之前对这里的了解。
  6. 其他：
  • 斯里兰卡属于英联邦的成员，母语是英语但是听起来有些怪，非英音非美音。
  • 去时导游说那里有点像80年代中国让我们做好心理准备，去后感觉确实比较破一些但是当地的那种文化还是非常不错的。
  • 当地人比较好客喜欢和你打招呼，当然有些景区也有人不断的在向你推销一些本地特产，哪里都有好人也有坏人，斯里兰卡总体来说还是比较好的。
  • 因为斯里兰卡人口不是很多，很多地方比较原生态有猴子、蛇和本地的一些动物旅游时还是需要注意别被骚扰到。
  • 感觉斯里兰卡消费有些高，但后来在网上查实际并不应该有那么高，所以和国内一样应该是旅游景点附近的东西相对比较贵，但这里也可以讲价钱
  • 前可以简单做一些攻略，譬如你可以看完我这篇游记，我是去前在网上找了一些游记看了看，另外也在喜马拉雅电台上找了一些斯里兰卡的音频游记听了听还是有一些准备的。

必备物品
多功能转换插头（如下截图多个usb接口很方便）、驱蚊水、防水袋、冰袖、帽子、防晒霜、小背包、雨伞、护照+电子签证、银行卡、数据线、丝巾、牙膏（当地旅店不提供）、纸巾和拖鞋等，其他物品根据自己情况而定。

Read More

多彩生活►旅拍&航拍

宝岛台湾团建

本文目录结构

磨磨蹭蹭终于写了个大框 台湾 游记（行程时间：2017.9.19-9.24），整个感觉 台湾 值得一去，以下是一些小体会：

  1. 台湾 旅游比较成熟不会出现宰客现象，旅游设施也比较齐全。
    2.消费感觉略高于 深圳 的平均水平，一顿饭大约在30元左右。去大的餐馆是有服务费的大约是整个餐费10%。
    3.景色宜人，特别是海边。
  2. 台湾 经济感觉有些萧条，虽然平均GDP还高于大陆但感觉不可持续，希望能早日回归。
    5.去 台湾 故宫有人说比较枯燥，但我比较喜欢，去时还要做好攻略，因为每一个藏品都有他悠久的历史和藏在它身上的故事，所以要提前做攻略。
    6.貌似 台湾 除了水果也没什么特产，像凤梨酥比较有名，但是和国内去 厦门 吃也没什么区别，还比较贵。
    以下这张图是iphone里在 台湾 每个地区拍的照片汇总截图：

###################################################################

整体行程

Day1 深圳 -> 香港 -> 台南 -> 垦丁
Day2 垦丁
Day3 垦丁 -> 宜兰
Day4 宜兰 -> 台北
Day5 台北
Day6 台北 -> 香港 -> 深圳
6天行程中从 台湾 的最西南到 台北 的东南，基本玩边了半个 台湾 。 那我从第一天行程开始介绍，整个旅游过程。
###################################################################

Read More

工作相关►总结笔记

Docker3.0项目总结

开篇

我们在2015年中的时候就在做Docker1.0（琥珀），当时主要针对离线场景到2016年初琥珀已经小有规模同时也解决了很多生产环境的问题得到大家认可。在2016年3月份中心内部开始讨论要做在线Docker版本，而这只是需求并不是目标，所以我们当时针对中间层（spp）业务进行了调研，设定了目标做业务的弹性伸缩，主要是通过Docker来解决资源的快速扭转，大家用机器时可以更方便拿到，另一方面是减少人为参与上下线，将有限的人力放到更重要的位置让大家能快速成长与学习。
围绕这一小目标， 从2016.3.31发出一封Docker邮件到目前已经有一年多了，内部经历了多次的PK，从技术选型、是否使用开源、人力的配备、项目的优先级等，外部也遭到很多的质疑，为什么搞了这么久没有上量，Docker搞了那么多版本有什么意义、Docker的长期目标是什么，是否可以保持现有体验等等。总感觉项目走在十字路口，选每条路都是对的，但每一条路都未必捷径，总是被挑战中，这里我承认有一点根本原因是，理想很丰满，现实很骨感，我们在谈理想时嘴上总挂着我们要把我们的运营系统往前在走一小步，多么美丽的理想，而落地到现实时，我们需要更多的时间、需要人力、需要每个人情怀、需要顶住外界压力、寻找更多合作团队一起努力才能达到目标。而这并非易事，本邮件主要总结我们在运作项目中遇到的问题、我们的思路、大家对项目的疑问等。

如何开发一个项目

因为我个人并不是专业的项目经理，所以项目开发的过程也是我学习的过程也在思考如何能把整个项目能做的更好能尽快达到短期小目标。前期我参考了软件工程的方法论需求分析、概要设计、详细设计、测试、维护和用户手册等，但感觉并不十分实用于互联网的项目管理，譬如详细设计基本拿到文档就可以开发写程序，而目前我们还做不到这样的详细设计。后期我参考了《打造Facebook》一书其中的一章个人感觉还是比较试用的，但再原有的基础上我也补充了一下本项目开发过程中的案例。

打造Facebook Docker项目
描绘远景，设置目标； 描绘远景，设置目标；
收集想法并排出优先级； 收集想法并排出优先级
跨团队沟通 跨团队沟通
告诉所有可能关心的人 设计产品
设计产品 指定责任人
指定责任人 定期碰头
定期碰头 了解进度，汇总报告
了解进度，汇总报告 发布产品监控数据
发布产品监控数据

描绘远景，设立目标

开篇中提到要寻找更多的合作伙伴才能达到目标，所以项目建立之初一定要描绘远景、建立短期、中期和长期目标，这样在不同的时间需要伙伴与切入点才一幕了然。以下使我们项目的一个基本项目流程图

Docker项目流程图

Read More

工作相关►总结笔记

Docker2.0项目总结

开篇

腾讯SNG（社交网络事业群，后简称“SNG”）事业群担负着QQ、Qzone、QQ音乐和相册等核心社交产品运营，从运营的这些产品就能看出部门的历史。笔者没有进入腾讯前在北京工作过多年，记得在2010左右北京的各种IT大会风起云涌当时可以看到各大公司分享自己的架构与运维理念但很少能看见腾讯的分享，当时很纳闷为什么看不到腾讯分享，多年后走进腾讯当年很多疑惑慢慢揭开了神秘的面纱。

从架构层级上腾讯和很多公司相同即接入、逻辑和存储但腾讯BG(Bussiness Group 事业群，后简称“BG”)制，外人可以理解BG为腾讯内部子公司，彼此有独立的方向、业务与架构，不同的BG架构不同（接入、逻辑和存储）， 与其他公司不同的是，腾讯在各BG架构上又多了一层“大存储”即（接入、逻辑、存储（短期）、存储（长期） ），这里大存储指各BG数据最终落到统一的BG下，即TEG(技术工程事业群)。以SNG为例接入使用qzhttp（web服务）逻辑之间调用关系用了l5（名字服务），程序开发有spp框架， 数据间传输使用了私有协议，存储使用了MySQL和一些自研的数据存储，可以看到腾讯这里走出了一条有自己特色的道路，它更多使用的是自研组件和私有协议，这也就解释了之前笔者的疑惑为什么很少看见腾讯的分享原因。相比很多公司使用开源组建在基础上做二次开发，但腾讯更多是学习开源组建再开发，区别是后者配置文件些许区别维护学习上有一定成本，但优势更加适合业务使用，足够的轻量级和安全，但问题是业务的需求量有限很多自研组建放慢迭代脚步，甚至停滞迭代。

那为什么腾讯内部的工具不走开源路线呢？ 开源接受的市场更多的需求，需要持续的打磨与迭代， 这问题也是笔者在入职腾讯后一直的疑惑 直到一次公司技术分享A同事的一个问题，A同事大概问的意思是腾讯现在在互联网行业内有一定的影响力与同等公司相比开源做的并不是很好，这是为什么？ 当时公司CTO(首席技术官，英文Chief Technology Officer，即企业内负责技术的最高负责人)张志东是这样回答的。首先对A同事问题的肯定，也介绍了这里的背景，早年腾讯业务爆发式增长工程师更多的精力是应对需求以及当业务发生故障时去救火，再者考虑的就是开源软件对数据安全的问题，如果本身能力未达到应用开源软件后遇到风险不能快速解决结果是致命性的。 这两点笔者身有体会特别是随着互联快速发展，网络安全很重要往各种暴库（csdn 索尼）等事件，做过一个公司的CTO需要更加关注用户数据的安全，这也是我们公司的底线用户安全置上。但Tony也说随着腾讯各个业务步入正轨我们也逐渐考虑去做一开源的工作，鼓励各BG开源。老板的一句话给我们带来更多的思考是如何去开源？ 而开源的前题也是如何更好的使用开源的工具在基础上有机会再开源，所以当时笔者也在想自己的业务上去寻找一些场景适合开源工具的解决方案。

Read More

工作相关►总结笔记

Docker1.0 项目

背景

由于历史的原因我们的机器目前还是单机或单集群对应一个业务模块的形式，优势应对爆发式增长扩容方便，成本结算简单。但是随着网民的饱和，相同业务模块下移动流量上涨，PC流量直线下降，很多业务出现了低负载情况，海量服务器运维中只要有1%的低负载（既机器利用率不饱和）规模也是惊人的，在实际运营中低负载+长尾模块机器数量可能达到了25%-30%之间，当然这里也包含业务对流量做了冗余与灾备，但是多个业务模块的灾备就会出现浪费资源的情况。我们从运营中发现了这问题的存在，而运维的核心价值也是通过技术优化，能在（成本、质量、效率与安全）四块做优化达到一个很好的收益，所以从2014年中我们开始做离线业务部署项目。项目的思路是通过高负载业务（离线计算）与低负载业务进行混合部署，提升低负载机器利用率同时逐步下线高负载业务的机器为部门节约机器成本。不过经过半年多的运营中我们也发现了很多问题，离线业务的负载均衡权重统一，但是混合部署后的机器负载不均有高有低，混部的结果经常会导致部分机器高负载影响业务，可以看出这里缺少监控负载的和业务合理的手段，经常导致高负载业务影响低负载业务，接口超时影响用户的情况，这是我们不希望看到的，所以总结经验教训，在2015年上半年我们重新打磨项目开发了离线业务混合部署（琥珀自动调度系统）项目，新项目与老项目相比通过docker技术将混部业务控制在容器中，消除争抢资源对业务影响，同时对容器流量进行根据负载调度，在此基础上实现了分时调度等功能。

负载调度演示（图1）

希望通过技术架构优化与升级来充分扎干硬件资源，为公司节约服务器成本。在开发过程中，相关业务也向我们提出了以下需求（已经实现功能见图2）：

  • 机器主动与被动下线不影响在线业务；
  • 可以方便的查看到系统运行状态；
  • 可以连接到容器内部查询日志以及debug程序；
  • 沉淀各系统日常数据，并根据沉淀的数据进行戳峰调度。 Web功能展示（图2）

Read More