May 23
转自:http://blog.jobbole.com/93905/
"hello world"它是最著名的程序。对于每个程序员来说,它几乎被认为是每种程序设计语言的第一个例子,那么这条消息是从哪里来的呢?
作为一个功能,计算机程序简单地告诉计算机显示“Hello, World!”。传统上,它是开发者用来测试系统的第一个程序。对于程序员来说,在屏幕上看到这两个单词意味着他们的代码可以编译、加载和运行,并且他们可以看到输出。
它是一个测试,象征着一个程序的开始。在过去的几十年,它已经成为了一个历史悠久的传统。在某个时候,所有在你之前的程序员在意识到他们成功与电脑进行通讯之后,都会肾上腺素急剧上升。下面将会介绍程序历史上最著名的两个单词开始是怎样出现的:
点击在新窗口中浏览此图片
Brian Kernighan(上面照片中的帅哥)创造了“Hello, World”,他是一本被广泛阅读的书籍(1978 年的《C 程序设计语言》)的作者。他在《C 程序设计语言》的前身(1973 年出版的《B 程序设计语言的入门教程》)中首次引用‘Hello World’。

main( ) {
extrn a, b, c;
putchar(a); putchar(b); putchar(c); putchar(’!*n’);
} 1 ’hell’;
b ’o, w’;
c ’orld’;


不幸的是,这位传奇人物自己也没办法明确地指出何时或者为什么他选择了“Hello, World”这两个单词。当在接受 Forbes India 的访谈中被问到是什么激发了他使用“Hello, World”这个名字的灵感时,他说他的记忆很模糊。“我记得的是我看到了一个卡通片,里面有一个鸡蛋和一只母鸡,并且母鸡说:‘Hello, World’”。
考虑到“Hello, World”代表着计算机编程对于大众是一种普遍现象的诞生,这组单词是很适合的。
当时,Kernighan 和他的同事 Dennis Ritchie(已故的 C 语言之父),都没想到这个语言和教程对今天的编程领域如此重要。因为这些想法只不过是 Bell 实验室(AT&T 的一个研究和开发分部)里面的一个研究项目。
虽然没人可以科学地解释为什么“Hello, World”会变得如此受欢迎,但是“Hello, World”程序标志着编程的历史论调上一个重大改变。下面让我们看下它的历史背景。
萌芽时期
虽然在今天很难想象,但是在 Kernighan 的书中出现“Hello World”之前,即二十世纪七十年代之前,计算机在大众心中是伴随着贬义的。它们是巨大的机器、非常慢、占据了整个房间并且需要科学家或者研究者全职进行维护保养。事实上,在七十年代末以前,计算机科学家编程都是用一叠叠打孔卡。

点击在新窗口中浏览此图片
人们普遍将计算机视为遥不可及的、复杂的和贵得离谱的设备,它们只预留给学术界的精英、国防或者政府。实际上,献身于计算机世界的行业巨头已努力地洗掉这个污名。想想我们已经走了这么远,以至于没有了我们的个人设备之后,切实感受到的焦虑感,这是多么令人惊讶。

第一次使用计算机的著名事迹之一发生在 1890 年的美国,当时自动电子制表机为超过 6 千万美国人计算数据。在二十世纪四十年代,Bombes 和 Colossus 计算机在第二次世界大战期间对德国人的电报密码进行解密。

二十世纪五十年代迎来第一台针对算术运算的商用计算机,像 Zuse 3 和 UNIVAC,但你需要上百万的美元才能买到一台。

从教育的角度来看,很多关于早期程序设计语言(像 FORTRAN 或者 BASIC)的书籍,都会提供这样一个观点作为书本的开始:计算机其实很有用的。这是根据算法学家和研究者 John Mount 的文章得到的。Mount 说“Hello, World”爆炸性受追捧表明一个时代的到来,那个时代里,计算机科学家不再觉得他们需要说服社会,去相信计算机的实用程序是有形的。

例如,在 1964 年的《My Computer Likes Me When I Speak Basic》一书中,介绍部分大体上谈及程序设计语言的意图。此外,第一个例子输出:“MY HUMAN UNDERSTANDS ME”。使用这个例子是为了加深一个不太流行的想法:人类事实上是可以与计算机对话的。1956 年的动态编程开始使用一些可以应用到普通计算的例子。

直到《C 程序设计语言》出现时,“Hello World”才真正地流行起来。
点击在新窗口中浏览此图片
Hello World’ 编程来了

触发“Hello World”传播的一个主要催化剂是 PDP-11(最早成功商用的微型计算机之一)的并行介绍。数字设备公司(DEC)一共卖出超过 600,000 台单价为 $10,000 的 PDP-11,这个价格远远低于通常需要花费数百万美元的计算机的价格。此外,PDP-11 的 16 位系列不需要穿孔卡片。这是首次你可以使用程序设计语言直接与一台电脑对话。

但是为了提高大众的接受程度,DEC 不能提及它是一台计算机。DEC 把它作为“程序控制的数据处理机”来进行推销,以此与过去的大型计算机撇清关系。随着更多的人购买可编程计算机,对《C 程序设计语言》这本书的需求也激增。

C 和 Unix 操作系统在 PDP-11 上首次流行起来。所以,紧接着出现支持新的 C 程序设计语言的商用计算机的热潮,驱使成千上万的人去阅读 200 页的《C 程序设计语言》。这也重新介绍了‘Hello World’。

在八九十年代以后,几乎每个用桌面软件工作的程序员都会拥有那本书的一份拷贝或者参考文献。至今已经卖出数百万份拷贝了。

开始学习编程可能会有很多不同的基础程序可用,但是到目前为止,‘Hello World’是最著名的。每个程序员会记住他们的第一个‘Hello World’,并以此作为他们开始编程的一个仪式。很多人可能没有意识到,但是每次一个程序员通过‘Hello World’这两个单词清除程序设计的第一个障碍后,他们所感受到的甜蜜和胜利的感觉,是经历过的超越历史的时刻。
May 9
开篇
     “古巴比伦王颁布了汉摩拉比法典,刻在黑色的玄武岩,距今已经三千七百多年,你在橱窗前,凝视碑文的字眼,我却在旁静静欣赏你那张我深爱的脸……”,想必大家都听过这首周杰伦演唱的《爱在西元前》,由方文山填词,歌词生动美妙不落俗套。作为周杰伦的御用作词人,方文山其实只有高中学历,但他才华横溢,创作了不少经典之作,有些作品甚至被收录进了学校的课本中。那么他是如何写出这么美妙的歌词呢?直到看了他的访谈笔者才了解到其实他的歌词大多来源于生活中的灵感,这首《爱在西元前》就是他在某日逛完博物馆后有感而发,他从现实的场景获得灵感再进行文字加工,从而文思泉涌,妙笔生花。其实运维工作也亦然,需要我们时时从工作中寻找灵感。笔者从事运维工作接近8年,多年的工作经验总结出一个道理:我们要善于从运维工作中发现问题,并根据问题及过往经验发明创造改进工具,接着再从发明创造中提炼技术,最后根据技术提炼原理。近来以Docker为代表的容器很火,很多互联网公司都在使用。那么Docker是如何获得互联网公司的青睐的,我们又应该如何来应用Docker,本章将从以下几个方面逐一介绍:
 我们为什么使用Docker
 离线系统业务架构
 Clip名字服务
 Clip名字服务与Docker应用场景



我们为什么使用Docker
     首先来看一下我们在运维中发现了哪些问题。以笔者就职的腾讯公司案例为例,腾讯产品战线很长,笔者所在的团队负责运维腾讯的QQ、Qzone等核心产品,而这些产品也算是中国互联网骨灰级的业务了,整体架构都有着复杂的历史背景。不仅团队的老员工发现架构逐渐产生的问题,团队新入职的同事也会指出与原任职公司比较架构存在的一些问题等等。如何将很多好的技术融入到我们的业务架构中,以解决产品的问题是摆在每一个运维架构师面前的难题。架构的复杂性与历史沉重的包袱决定着牵一发而动全身,并且架构支持的业务为近半数的中国互联网网民所使用,还有着不少的优点,在对其进行改进优化之前,我们主要先分析了它的优缺点:
  优点:目前还是单机或单集群对应一个业务模块的形式,彼此间没有交集与复用(见图1),其架构优势应对爆发式增长扩容方便,成本结算简单,架构形成的历史原因更多的是前者流量的爆发增长。
点击在新窗口中浏览此图片
图1
  缺点:随着网民的饱和,相同业务模块下移动流量上涨,PC流量直线下降,很多业务出现了低负载情况。海量服务器的运维场景中即使只有1%的低负载规模也是惊人的,在实际运营中低负载+长尾业务下的机器数量可能达到了25%-30%甚至更高。当然这里不排除业务对流量做了冗余与灾备,但是多个业务模块的灾备就会出现浪费资源的情况。除低负载与长尾业务外,为了应对业务的流量徒增团队为产品留出了足够富裕的Buffer资源以应对某业务徒增,而导致这些资源的实际利用率不高。

分析了优缺点后以及运营中发现的这问题后,从2014年中我们就开始着手离线业务混合部署项目。项目的思路是通过高负载业务譬如音频转码、视频转码、图片人脸计算和图片特征提取业务(注:后统称“离线业务”)与低负载、长尾业务和部门buffer业务进行混合部署,来提升机器利用率并同时为部门节约机器成本。不过经过半年多的运营,我们也发现了很多问题:
  在低负载与长尾业务上部署离线业务,如果离线业务抖动出现大的CPU毛刺(特别在晚高峰时段)就会影响用户的使用体验,从而导致部分投诉产生的情况。
  部署在buffer池上的离线业务,由于在线业务申请机器导致机器上的离线环境没有及时清理,继续运营影响在线业务的正常使用。
这两个问题比较有代表性的问题也是我们最不希望看到的,所以总结经验教训后在2015年上半年我们又重新打磨项目开发了新版离线系统,新项目与老项目相比通过Docker技术将离线业务与在线业务的低负载、长尾业务和Buffer池进行了部署,从而顺利解决了上述的问题。这里主要利用了Docker的三个优势:
  Cgroup对资源的隔离让离线与在线业务彼此间对资源使用有了保障;
  命名空间,让相同框架多业务跑在相同物理机上成为可能;
  容器的快速回收上线下线,使用Buffer资源时不再为回收离线资源而头痛。



离线系统业务架构
上文中笔者提到QQ、Qzone的整体架构着很复杂的历史背景,而希望仅仅通过Docker或一两种工具来解决现实存在的所有问题是不现实的,所以我们在保持现有架构与内部用户习惯的基础上另辟蹊径逐渐解决我们产品运营上的一些问题,具体部署见图2。
点击在新窗口中浏览此图片
离线系统业务架构(图2)

从图2中可以看到在部门Cmdb基础之上,我们建立了数据分析系统,通过它可以分析出哪些是低负载业务,哪些是时段低负载业务。在此基础之上我们使用Clip名字服务系统在Cmdb基础之上重新建立了业务之前的IP关系,并根据重新划定关系的IP进行了业务流量与资源快速的调度。其中Etcd为服务发现工具,根据Clip名字服务系统传入的信息通过Confd重新生成HAproxy的配置文件并热重启它,离线业务流量通过HAproxy的虚拟IP屏蔽底层资源信息,建立离线与资源的生态供应链,同时上层监控与调度均为Clip名字服务系统。这里读者有可能会有疑问,尽管HAproxy的虚拟IP屏蔽底层资源信息(其为动态的),但如果程序有问题,如果能快速到机器上去debug自己的程序呢? 这里我们使用的是Clip名字服务。




Clip名字服务
Clip(http://blog.puppeter.com/read.php?7)是一个名字服务C/S架构,它将传统的IP管理维度替换为名字服务即有意义可记忆的String。Clip将IP对应的String关系保存在Server端。Client端可以下载SDK,通过SDK遍历Server端的String对应IP的关系,并在本地对获取的IP模块关系进行重新的组织与编排。传统服务器IP方式与String方式相比,String方式有3点优势:
  传统IP管理方式,IP由4组无意义的数字组成,比较难记忆。String更方便记忆;
  管理海量服务时,IP相似经常会导致运营故障,譬如A模块(10.131.24.37 )和B模块(10.117.24.37),后两组数字一致,系统惯性的认为B模块就是A模块,发送配置导致线上故障。通过string管理方式可以规避此问题;
  String 可以解析1个IP,也可以解析一组IP ,根据IP也可以反解析String对应关系,使得管理一组服务更加方便。
    Clip中的String由四段(字段含义idc-product-modules-group)组成,读者会发现String与Cmdb的结构很像:四级模块定位一个服务。但是为了充分利用资源我们的业务要求一个IP可能要对应多个服务,不同的服务有自己的波峰与波谷,在相同的IP上只要保证各业务的波峰不重叠就满足了业务的需求,也充分了利用资源。而在一台服务器上混合部署不同的业务模块,四级模块就只能定位到服务的IP级别,而无法精确定位到真正的服务,所以Clip名字服务在Cmdb的基础上增加了port端口,即五段(字段含义idc-product-modules-group-port)定位一个服务。我们可以将动态的IP通过Clip接口注册到指定含义的String上,通过Clip自带工具来解析实时的String对应IP关系,譬如:

# clip cstring -q idc-product-modules-group-port
192.168.0.1
192.168.0.2
192.168.0.3
192.168.0.4
192.168.0.5

Clip数据存储结构分为两层:
关系层保存了String对应IP或内部系统Cmdb的模块关系(见图3)。
点击在新窗口中浏览此图片
Clip名字服务关系表(图3)
关系层数据含义见表1
点击在新窗口中浏览此图片
关系层数据含义表1
数据层保存了String与IP的具体关系(见图4)。
点击在新窗口中浏览此图片
Clip名字服务数据表(图4)
点击在新窗口中浏览此图片
Clip名字服务在存储String对应IP关系基础上,在SDK上还提供了远程端口扫描、远程ssh、远程文件拷贝和查找String关系结构的工具子命令等,更多可以见http://blog.puppeter.com/read.php?7。




Clip名字服务与Docker应用
如笔者上文所提,离线系统的建设思路就是将离线业务通过Docker快速的部署在资源空闲的机器上,而空闲的机器是通过数据分析系统长期分析沉淀的结果,Clip名字服务就是这两种资源建立联系的桥梁,但只有Clip绑定关系还是不够的,还需要建立绑定关系String对应Docker环境的关系,所以在Clip名字服务的基础上我们又扩充了Docker的资源关系表。
点击在新窗口中浏览此图片
Docker资源关系表图5
其中Docker资源使用的关系表的字段含义见表3:
点击在新窗口中浏览此图片
我们来看一个需求案例:某视频转码业务在上海需要使用资源约1000核心,对应的关系表为表4
点击在新窗口中浏览此图片
由于buffer资源不时在变动,我们需监控String (sh-buffer-qq-video-2877)整体核数是否低于mcount值,如果低于则出发自动扩容策略。同时也需针对Docker资源使用关系中的app_port字段来监控整体String (sh-buffer-qq-video-2877)业务是否处于健康状态。在这里我们沉淀了String (sh-buffer-qq-video-2877)的一些基础数据如负载、内存、网络和磁盘IO等为资源的调度奠定的基石(见图6)。
点击在新窗口中浏览此图片
离线运营系统图6
Dec 15
通过Puppet管理大量机器的过程中会经常遇到连接超时的情况,所以通过Shell脚本包装Puppet Agent随机连接也是一种很好的方法,以下为连接过程脚本。



Puppet连接过程架构
点击在新窗口中浏览此图片



Agent连接Master脚本(注:部分内部为了安全被替换为中文注释)


#!/bin/bash
# author: wds
# time : 20151212

## init
PATH="/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin/"
export PATH
export LC_ALL=POSIX
export LANG=en
_PWD="/etc/puppet"
_PUPPET="/usr/local/services/puppet/bin/puppet agent"
_HOST="puppet.example.com"
_LOG_TIME=`date +%Y%m%d%H%M`

[ ! -e ${_PWD}/lock ] && mkdir ${_PWD}/lock
[ ! -e ${_PWD}/log ] && mkdir ${_PWD}/log
[ -e /etc/puppet/log/ ] && find /etc/puppet/log/ -name "*.log" -mtime +3 -exec rm -rf {} \;
[ -e /etc/puppet/lock/ ] && find /etc/puppet/lock/ -name "*.lock" -mmin +17 -exec rm -rf {} \;

## function
getip()
{
    IPADDR=`ifconfig eth1 | awk '/inet addr/ {print $2}' | cut -f2 -d ":"`
    if [ "x${IPADDR}" == "x" ];then
        IPADDR=`ifconfig eth1 | awk '/inet addr/ {print $2}' | cut -f2 -d ":"`
    fi
    echo $IPADDR
}

netlog()
{
    #打网络日志
}

#content title
sendalarm()
{
    #发送告警
}

rand(){
    min=$1
    max=$(($2-$min+1))
    num=$(date +%s%N)
    echo $(($num%$max+$min))
}

clip_ini(){

if [ ! -e /usr/local/services/clip/clip ];then
    netlog "clip not exists fail"
    exit
fi
# clip 相关介绍http://blog.puppeter.com/read.php?7

if [ ! -e /etc/facter/facts.d/clip ];then
    ipaddress=`getip`

    clip=`/usr/local/services/clip/clip cstring -i $ipaddress`
    if [ ! -e /etc/facter/facts.d/ ];then
      mkdir -p /etc/facter/facts.d/
    fi

    echo -n "#!/bin/bash
    echo \"clip=$clip\"
    " > /etc/facter/facts.d/clip
    chmod -R 777 /etc/facter/facts.d/clip
fi

return 0
}

hostname=`getip | sed 's/\./_/g'`
if [ "x${hostname}" != "x" ];then
        hostname $hostname
fi

##############################################################################################
#/usr/local/services/puppet/bin/puppet agent --server puppet.example.com --test

## first  首次连接
if [ ! -e ${_PWD}/lock/first.lock ];then
    sed -i '/puppet/d' /etc/hosts
    echo "IP $_HOST # puppet" >> /etc/hosts
    res=`$_PUPPET --server $_HOST  --test | tee -a ${_PWD}/log/puppet.log | grep "Finished catalog run" | wc -l`
    if [ $res -eq 0 ];then
    netlog "puppet first fail"
    else
        touch ${_PWD}/lock/first.lock
    fi
fi

## second 二次连接

if [ ! -e ${_PWD}/lock/second.lock ];then
ipaddress=`getip`
clip=`/usr/local/services/clip/clip cstring -i $ipaddress`
if [ "x$clip" != "x" ];then
  touch ${_PWD}/lock/second.lock
fi

idc=`echo $clip | awk -F '-' '{print $1}'`
if [ "$idc" == "tj" ];then
    _host='IP'
elif [ "$idc" == "sz" ];then
    _host='IP'
elif [ "$idc" == "sh" ];then
    _host='IP'
else
    _host='IP'
fi

sed -i '/puppet/d' /etc/hosts
echo "$_host $_HOST # puppet" >> /etc/hosts
fi

## app
##########################################################################################
if [ -e ${_PWD}/lock/puppet.lock ];then
exit;
fi

clip_ini
wait
touch ${_PWD}/lock/puppet.lock
rnd=$(rand 1 5)
sleep $rnd
res=`$_PUPPET --server $_HOST  --test | tee -a ${_PWD}/log/puppet.log | grep "Finished catalog run" | wc -l`
if [ $res -eq 0 ];then
  rnd=$(rand 1 20)
  sleep $rnd
  res=`$_PUPPET --server $_HOST  --environment=${_ENVIROMENT} --test | grep "Finished catalog run" | wc -l`
  if [ $res -eq 0 ];then
    netlog "puppet cluster fail"
  fi
fi

netlog "puppet succ"
rm -rf ${_PWD}/lock/puppet.lock
exit 0;
Tags: ,
Oct 28
Clickheat是一款网站热力图工具,它可以获取用户在网站的行为,并以图形式呈现在页面上,借助它可以了解用户行为以便有针对性的对网站进行优化。以下是内部系统的一个案例

点击在新窗口中浏览此图片

Clickheat由PHP开发,下载后将源部署到自己的服务器上,并在网站页面中嵌入相应的JS代码来生成点击热图,然后通过调用相应的页面查看。Clickheat官方网站(http://www.labsmedia.com/clickheat/index.html)
Oct 27
作者:研究僧
文章地址:http://blog.puppeter.com/read.php?13

开篇
虽然工作多年,但是对系统技术痴迷热情从未改变,所以在2015年初,历时1年多写的《Puppet权威指南》书发行了。在与很多朋友技术交流过程当中了解很多人也有类似写书的想法,经常有人问你出书的流程是什么? 如何来写一本书?出书的收益又如何?等问题。综合这些问题,我也来分享一下:

如何萌生写书想法;
写书的流程是什么;
如何将过程转化为收益。

希望通过介绍整个过程,能让更多有意的朋友能为业界提供更多的思路与创新技术(注:由于笔者能力水平有限,在写作过程中难免会有错字、语句不通顺等情况。如果大家有任何疑问可以给我留言,我会尽快回复与更正,非常感谢)。


如何萌生写书想法
回忆了一下,首先从来没想要写书,只是偶然的机会而已。在2001年左右,上高中时很喜Photoshop和3Dmax,在那时我就已经会安装Windows 98操作系统,在班级中公认的是一个计算机高手。另外,我也经常买《电脑报》、《网友世界》和《黑客X档案》杂志,通过XCAN来扫描远程服务器开放端口,并根据扫描后端口确认是否有漏洞,这些对于那时的我会带来很多的成就感与自豪感,记忆中曾多次一条命令就可以让网吧远程的系统蓝屏,但有一次在网上遇到了牛人,他能随意改我的QQ密码,盗取我的163账号,查IP地址能定位到我的家门牌号,那一刻我觉得自己弱爆了,后来经常与他交流学习经验,那时我最不喜欢学习编程语言,而他说你要做为一个优秀的黑客就要去学习编程语言和网络协议,也是那时他让我第一次知道TCP/IP协议的三卷书,通过与他交流与指导,我开始自学C编程语言,学了才知道C语言并没有想象中那么难。

后来上了大学,操作系统中学了Linux,了解他历史的都应该知道玩Linux才是真正的黑客,所以那时去电脑市场买了一个Redhat6.0版本的系统盘来安装,安装后不知道怎么用,在网上查资料时知道了www.chinaunx.net(简称CU),那年是2006年,因为我的CU ID(研究生)注册时间就是2006年。从CU学到了很多东西,譬如记忆深刻的《门户网站运维abc》、《Shell能力测试》和《Shell基础20篇》等都是很好的学习资料, 还有一篇文章来描述如何学习Linux,大概中心是要想学好Linux;
多看书;
多实践;
多总结沉淀;
遇到问题自己查找资料解决,解决不了再寻求帮助;
如果学习的知识点都掌握了,多去帮助他人解决问题,其实帮助他人也是自己学习的一个过程。
所以,在CU经常找别人问的问题,看是否能解决,如果解决不了再去网上找解决思路与过程,那时也是因为这原因,我写了很多文档,由于看了Shell编程13问的文章,忽然觉得我的文档总结可以写成一本书的形式与别的朋友进行分享,经过对文档总结提炼与打磨,最终在2008年写出了第一版本,不过现在已经找不到最初的版本了,在电脑里找到了2010年最后变更时间的书,无意间人生的第一本书就这样的写完了。

2008年在北京工作后,一天在QQ忽然有人问我,看你CU比较活跃是否可以可以来我们这里帮讲一些网络的课程,我抱着试试看的态度应邀去了华章的编辑社,去了才知道这是有名的机械工业出版社,我很喜欢买他们书。到了后是一位美女来接我,交谈中我说我写过书,美女说是否可以发我看看,几天后我提交了一份书的原本发给编辑社,美女帮我指定了出版策划(杨福川),第一次与福川见面时在中关村的麦当劳,感觉一见如故与技术人交谈很开心,他看过我给的文档后,给了我很多出书的建议,说对于刚出茅庐的我书的内容还是很好的,但对于出版来说要走的路还要很多,不过也鼓励我,希望有机会能合作出一本书。就这样几年过去了,应该是2012年系统架构师大会,再次遇见福川,福川问是否有兴趣来写书,我说OK没问题,正好由于内部部门产品变动,我负责的系统没有运营工具,我对Puppet进行研究并在线上应用。那时Puppet知道人并不是很多,所以一拍即合开始写人生的第二本书《Puppet权威指南》。



写书的流程
下定决心后写书并不复杂,以下为写书流程:
1)寻找一个靠谱出版社,因为他会有渠道帮你做后续推广;
2)确认写书的标题与大纲,其中大纲很重要,有一个目标才好量化时间与写作进度。写作大纲中一般还包含选题思路、读者对象、内容简介、市场分析、卖点分析、作者简介和营销建议这7项;
3)签约合同,合同是双方利益保障,对于出书者来说写完出版社不出版,可以通过合同来约束。当然,反过来没按照预定写出来,还是要陪违约金的(这也是签约后动力之一)。除此之外,还要确认付款方式,两种:
方式1:一次性买断书的版权,即一次打完所有歀。
方式2:是按出版发行量计费,根据书的售卖情况打款(我签约的这种)
大家可以自己来确定付款方式(写书并不挣钱,但是收益还是有很多的,一会会介绍)。
4)合同确认后,策划会分配一个编辑给作者。我的编辑(孙海亮)海亮给我的感觉三个词形容,积极、专业和耐心。编辑会把控整体的进度、写作风格、语句是否通顺、是否能很好的读者学习了解书中的专业知识内容,然后就是定期发文稿给编辑;
5)最终出版社收到完整的书稿(齐、清、定)后会制定编辑加工计划,并以书的形式打印出来各章,确认排版与最终效果是否一致,前后有三次校对过程;
6)最后确定封面,出版与推广;
7)根据约定出版社付稿酬。

流程中有很多值得分享的案例:
案例1:(做任何事,大多数人都会有一个热情期,当热情变成负担,这时如何来磨练自己让负担再转为热情?)
开始我写书很有热情第一个月就写了两章,将文稿发给海亮很快回复了我的邮件,当我打开文稿到是挺喜庆的,满篇的红字,感觉像老师改小学生作文一样,在其中提出了很多意见与建议,如何从读者的角度来写书等,其实那一时刻热情已然不在,更多的是觉得变成的负担,心想如果按照这样写下去何日能写好,用一个月写的文稿按海亮要求基本要从改一遍。果不其然,开始一个月写两章,到半年时我才写了4章。不过,需要承认海亮提的意见是非常好的,在写过第6章回头再看的时候,首先觉得是有成就感的,因为我真的总结出了很多内容,接着对文章不断的实践与打磨,我对Puppet认识也更加深入,所以日常的实践打磨到后续的价值转化,最后负担又转为了热情。

案例2:(出版社很专业从一些细微的案例可以体现到)
在Puppet编程语言中有自己的if..else,如果作为我专业人士来描述,我会写if 为真,怎么样,否则为假怎么样。海亮很耐心的和我解释这里应该如何写,建议借鉴谭浩强老师写的C语言编程中的对if..else描述,当时我做了对比差异确实很大。
另外,我的书大约是2014年10月份最终完成,11月份印刷完毕,直到2015年1月份才正式出版,推迟两个多月,原因是很多书店年底会清货,11月份出版很容易被清理到书店不容器看到的地方,所以推迟发行。我相信这些建议与意见都是从日常工作中摸索总结出来的,是专业的表现。

案例3:(工作+写书的时间分配)
如何的合理利用时间,通常我是周一到周五每天早上拿出半小时来阅读之前写的内容,中午午休1小时来实践Puppet,晚上1小时来继续写Puppet 。周六也拿出半天或一天时间来写和改,保持一个节奏,这样会比较轻松一点。

案例4: (如何丰富写作内容)
如果单写Puppet工具应用确实内容不是很多,所以我从对比角度出发,首先是业界流行的配置管理工具都有哪些(Puppet vs Cfengine vs Chef)他们优缺点是什么、我为什么选择Puppet、与老牌配置管理工具Cfengine相比Puppet为什么可以弯道超车、Puppet都谁在应用它、未来前景如何、它整套架构与运行原理如何、到最后实践如何应用它、都哪些场景适合使用它等。Puppet与很多工具软件一样,官方提供了详细的文档(http://docs.puppetlabs.com/)我们可以从这里获取很多信息。更主要的是获取信息后就是如何应用在自己的工作场景中,解决了自己实际问题同时也让读者在真是需求场景下,能够印象更加的深刻。

以下为写作过程中点滴
点击在新窗口中浏览此图片


如何将过程转化为收益
看一本书容易,但写一本书还是挺难的,需要有毅力和时间去写,写的过程中需要不断的对软件应用、实践与打磨,具备了这些,我们就肯定会从写作过程中得到收益。而写书除了money更多是无形的收益,其中对于我个人的职业技术生涯收益,我抽象了以下五点:

1)总结沉淀与转化能力
写一本运维工具相关的书,不但要对工具了解,还要了解工具的历史,以Puppet工具为例它的作者(Luke Kanies)是一位优秀的运维工程师,有着多年的运维工作经历,做运维的都有过类似的经历接手一套产品相关的运营系统没有运营文档或者运营文档不全是很悲剧的事情,当然有的公司会强制要求员工写文档或者Wiki,优势是当系统交接时,被交接的对象会通过文档绕过一些坑,而且这也是比较好的习惯,但也有他的缺点就是这些系统文档或Wiki并不实时与准确,相信Puppet作者也有过这样的经历,所以Puppet的解决思路是以编程语言形式,将当前系统所需要的安装软件包配置描绘出来,通过辅助工具还可以以图形式看到模块之前的依赖状况,而这一切都是实时的,一旦错误线上马上会体现出来,Puppet思路很好的解决的我们曾经面临问题。而对于我后续做运营工具的思考,我的总结是“从运维过程中获取经验,根据经验发明创造改进工具,接着根据工具创造提炼技术,最后根据技术再提炼原理”。有理由相信这也是Puppet开发运和营过程中的体现。

2)模仿能力
如果领导让我开发一套配置管理工具,相信我是有能力做出来的,但我也相信开发出来的配置管理工具只能满足临时的需求,长期来看它根据需求要不断的完善、重写与迭代,而配置管理系统在业界有很多,譬如Puppet、Ansible、Cfengine和chef等,他们均是配置管理工具,其实更好的方式是使用它们,模仿它们和改造它们为我们工作所用,因为它们有自己的开发社区、有多年的积淀、有非常好的思想能让你去借鉴、它们像一种协议一样统一了大家的思想,而这种思想对未来应用到其他领域是十分有帮助的,所以这里如何借鉴与模仿很重要。

3)换位思考能力
对于一个专业的互联网从业人员来讲,希望把书介绍的尽量详细与专业,书中可能会有一些工作中的术语,譬如“灰度”对于有工作经验的朋友肯定知道他的含义,但是对于那些刚入行的朋友却不知所云,所以我们要换位思考,以读者而且是刚入行的读者角度,尽量的白话书中的专业术语。这种换位思考能力不但可以应用写书,还可以在生活与工作中得到借鉴。

4)沟通与分享能力
思想就是武器,能说才是火力,光有武器火力不太猛还不行,如何在写书过程中不断的补充武器来提升火力很重要,因为任何一行业都要有交流沟通,特别是互联网行业尤为突出,所以总结每一章后,要想如何把他讲出来分享给其他人,这种分享过程可能先是文章、然后是技术博客、接着抽象出原理,最后是与同事来分享它,提升自己沟通与分享能力。

5) 运营能力
等书出来了,最后就是自己的运营能力。
引用
网上有一篇文章(Google通过Puppet管理超过6000台的苹果桌面操作系统)地址:http://my.oschina.net/HankCN/blog/180105
,我个人觉得这是一句有炒作的嫌疑,当时Puppet管理服务器能力并不是很强,而Google是很多技术公司的标杆,所以此新闻一出有一定的炒作意义,既然标杆用的都是Puppet工具,相信它也可以用在更多的公司中,而之所以Puppet使用广泛可以弯道超车与他的公司运营能力也有一定的关系。


最后,我想说的是写书分为两种,一种是有时效性的,一种是相对没有时效性的,TCP/IP三卷书就是相对没有时效性的,如果TCP/IP协议不变,写一本这样的书收益可以一直延续下去,而我写的工具书是有时效性的也许是1-2年 ,因为Puppet版本是在不断的迭代变更,但不管他如何改变,他值得学习的创新思路是永远不变的。所以走过这条路,也许绕了很多弯,调整心态,坚持走下去,即便是弯路,也可以收获美景。



鸣谢
很多书会在开篇提起感谢很多人,开始没什么感觉,写过书之后才体会到了这一点,因为有了你们的支持,才会让我坚持又坚持完成这本书,所以这篇文章最后要感谢曾经在写作过程中帮助过我的人,特别是我的老婆,感谢。



参考资料
Puppet labs官方网站:https://puppetlabs.com/
Ansible:http://www.ansible.com/
Chef:https://www.chef.io/chef/
Cfengine:https://cfengine.com
Puppet作者经历:http://blog.puppeter.com/read.php?10  
Shell编程13问:http://bbs.chinaunix.net/thread-218853-1-1.html
Shell能力测试:http://bbs.chinaunix.net/thread-476260-1-1.html
门户网站运维abc:http://bbs.chinaunix.net/thread-1281178-1-1.html
Shell基础20篇:http://bbs.chinaunix.net/thread-452942-1-1.html
Luke Kanies(Puppet作者linkedin):http://www.linkedin.com/profile/view?id=ABQAAAA6kLcB06__Nn-a_DEULHGnaTzLR2wPp-c
谁在用Puppet:https://puppetlabs.com/about/customers
分页: 6/7 第一页 上页 1 2 3 4 5 6 7 下页 最后页 [ 显示模式: 摘要 | 列表 ]