Wds的技术博客

作者：研究僧
文章地址：http://blog.puppeter.com/read.php?54


《开篇》
云南在没去时对那里了解不是很多，印象中的天应该很蓝有玉龙雪山和米线等其他了解真的很少。而本次行程还是有点急没有做任何攻略，甚至在出发的前4天还在和老婆商量是去云南还是泰国，最终还是选择了云南，开始还在想选哪个网站的旅程是去哪还是携程或是土牛最终我们选了携程觉得应该更靠谱些，行程选完了解准备做一下攻略才发现云南负面新闻真的很多，丽江打人事件、大理打人事件等，忽然感觉没有了安全感，不过行程都已经确定只能硬着头皮去，下面我就来分介绍一下整个行程。

---

整体行程分以下几类来介绍:
#整体行程路线#
#美食环节#
#购物环节#
#整体体验#

---

1整体行程路线
我们参加的是（http://vacations.ctrip.com/morelinetravel/p1830465s30.html?RepeatAction=Vacation_Repeat_PkgDetail）团，整体行程是深圳->丽江->香格里拉->大理->丽江->深圳，行程共6天5晚，其中第一天和最后一天为自由行，来回的航班时间由自己确定时间，选定出发与返程时间后旅行社帮订机票。

第一天
我和老婆选的早班飞机6点吉祥航空航班飞往丽江经停广西北海，大约10点左右到达丽江机场，云南是高原天气非常不错，在广西路上还看不到地面全是云，到了云南境内就可以看到地面了飞机路过了有一片很大的湖，在云南人们都会把湖称呼为“海”，后来我反映过来其实在飞机上看到的那个大湖就是大理的洱海，真的很漂亮后续会介绍到，以下视频通过ipad拍摄。


飞机很准时10点20左右到达丽江机场，那几天云南的天气也非常不错蓝蓝的天偶尔飘着一朵云彩。旅行社有接机从机场到住的酒店大约40分钟。我们住在丽江古城的王府酒店也就是丽江古城内，你知道进入酒店放下行李先要确认的是酒店防火通道，一旦遇到紧急情况好知道怎么逃生，不过酒店是一个二层的小楼路很宽不会出现逃生拥挤等问题，以下是一张酒店内景照片，因为我们参团的时间是年后旅游淡季，酒店有些冷清所以更没有必要担心紧急情况逃生问题。


[img][attach width=500]155[/attach][/img]
放下行李休息片刻我和老婆准备出去转转顺便吃些东西，关于吃可以放到一起说，这里对吃就不单独介绍了。第一天都在丽江古城（来自百度百科：丽江古城位于云南省丽江市古城区，又名大研镇，坐落在丽江坝中部，始建于宋末元初）。这里来介绍一些我对丽江古城的初感受，从机场到丽江古城的路上司机师傅就说了丽江原有人口30万人，现有外来人口300万+人所以丽江古城已经被商业化很严重，建议不要在古城内买东西，而从我实际观察感觉如导游所说基本全是商铺，走在丽江古城的路上有点感觉在北京的后海或者南锣鼓巷的感觉。

与北京反差的是人比较少，当然也可能是旅游淡季的原因，这种体验就非常好了。



我估计有些路是防古修的，但也有些路应该是历史上遗留下来的，譬如以下截图



地很光滑宛如玉石般。
由于云南在地震带上所以房子建的都不怎么高，而古城更是如此。上学时我觉得一个城市的好坏看的就是楼有多高，但是多年后我感觉这是错的，因为很多城市为了搞经济把楼修建的都很高，而现在去任何地方都是千篇一律，没有什么独特性唯独丽江这种感觉非常不错。

忘记说丽江古城是需要收古城维护费的80元，看网上攻略古城外有很多大妈大姐会以很低的价钱带你进古城，通常是骗人的需要小心不要贪图小便宜。

丽江古城晚上是不收古城维护费的，我觉得白天进古城拍照效果更好也很漂亮在古城内白天还可以看到玉龙雪山

白天有白天的美，晚上也有晚上的好，晚上人会更多些古城也灯火通明，古城的两个房子间可以看到圆圆的大月亮挂在天空很像一个大月饼，这种感觉百年前的人看到的风景与现在看到的风景应该是没什么区别的。

古城内什么都有卖的，云南有名的是茶当时我们进店品尝了一下是花茶，我本人对茶不是很了解，只是觉得很好喝所以准备买一点，但只装了很小一袋子价格就非常高，还好当时查了一下淘宝了解了一下价格最后没有买，这也让我想起早上司机师傅说的话，确实古城内买东西要注意，另外云南本地只产普洱茶，别的茶还要看一下产地再买。

云南少数民族比较多，早上司机师傅说丽江原有人口30万，随着旅游热涌入很多人，从丽江古城内我体会到这一点很多商家都是全国各地人，原住的少数民族也能看到但是都在做一些小生意，譬如在这小灯前许个愿把他放到边上的小河中，这些人都是穿着少数民族的衣服人在做。

少数民族的文字。


夜晚的丽江古城非常喧闹很多小酒吧都开业，很多歌手在深情的唱歌仿佛把你带入他的世界。这里推荐大家两手歌曲丽江街头都会有放《小宝贝》和《一瞬间》，是通过当地的手骨来伴奏的两手歌曲很好听。 同时你走在路上也经常会看到有卖手鼓的小店一位美女在敲着手骨放这两首歌，有的会做生意长的漂亮的美女还边敲手鼓变做手机的直播。





第二天
第二天主要行程为 玉龙雪山->甘海子->冰川公园（大索道）-蓝月谷->（白水河）-玉水寨->束河古镇（小马车）->《丽江千古情》。
早上6:00起床吃饭，7点导游带我们集合出发，导游是本地的哈尼族人，我们这个团是全国各地来丽江后后组的团，团友共16人（包含一个小孩）5家人。出发第一站到旅行团指定地点配装备，因为玉龙雪山海拔比较高很多人会有缺氧反应，所以行程中会赠送小的氧气瓶和到玉龙雪山上的棉衣(注：海拔每上升1000米温度下降6度，千万不要觉得天气很好的情况下不需要租用棉衣，因为山上山下温差很大)，氧气是每人一瓶如果不够可以再买大约是80-100左右1瓶，这个建议还是可以多买一到两瓶备用。
    离开供给站后前往玉龙雪山，玉龙雪山有个体验比较好的地方，上山通过索道，但每个旅行团需要提前预约你上山的时间，不到上山的时间只有排队等候（不知道这点是否学习了奢侈品店，譬如香港卖包包，为了保证游客的店内体验是限制人数进入的，可以让你尽情的享受买包包的过程），进入景区会查你的身份证还是比较严格。



因为人不多，我们排了一会大约9点左右就上了索道，正式前往玉龙雪山，玉龙雪山海拔5000多米，索道到的位置有4506米，索道上升还是比较快的大约10分钟到达海拔4500多米观景处，索道已经安全运行10+年所以放心。每个索道的车里大约可以坐6个人，坐满后还有一些比较宽松的地方，建议上山前带个所料袋因为缺氧和索道摇摆可能会有晕恶心的情况，带袋子以防万一。



玉龙雪山全景照


到山上后会感觉有点爬10层楼气喘心虚的感觉，有的会头痛恶心或恶心这都是高原反应只有吸氧来缓解，但建议在山下要提前吸氧等到真的头痛恶心再吸氧就比较晚了，到山上每隔10分钟要吸氧一次

到山上大约游览时间有40分钟左右，其实呆时间长也没有什么好呆的，主要是拍拍照在上面呆时间长会缺氧另外也比较冷，我们去的那天天气算比较好的万里无云在山上可以看到蓝蓝的天，从来没有这样零距离接触过蓝天很漂亮。
从山上下来前往蓝月谷，蓝月谷，其前身为早前人们所熟知的“白水河”。在晴天时，水的颜色是蓝色的，而且山谷呈月牙形，远看就像一轮蓝色的月亮镶嵌在玉龙雪山脚下，所以名叫蓝月谷。而白水河这个名字是因为湖底的泥巴是白色的，下雨时水会变成白色，所以又叫白水河。有人会问到为什么蓝月谷的水是蓝色的，当时导游有介绍但我忘记了，（来自百度百科：蓝月谷（白水河）的河底泥是白色的细泥，胶着性比一般的河床泥要好，下雨的时候由于雨水冲刷形成对河底小的冲击力，泥就扬起和水混合变得浑浊，就像是白色的河水，平时不下雨的时候，泥就沉淀在河底，呈蓝色的河水。）

实际身临其境的感觉还是非常好的，风景很漂亮 。



从蓝月谷出来我们驱车前往玉水寨，玉水寨很小没有太多好玩的，建议自驾游就没有必要前往了，所以这里就不再做介绍。下午我们去了束河古镇，纳西语称“绍坞”，因村后聚宝山形如堆垒之高峰，以山名村，流传变异而成，意为“高峰之下的村寨”，是纳西先民在丽江坝子中最早的聚居地之一，是茶马古道上保存完好的重要集镇。在束河古镇是骑小马穿行的，束河古镇与丽江古城差别不大，唯独比丽江古城人更少些，貌似不收古城维护费，所以也没有怎么拍照片。时间来到下午3点多我们驱车又回到玉龙雪山不远的丽江千古情表演场地，演出4：30开始大约1小时表演，这个还是值得推荐的，后来我注意了一下丽江很多公路上都由丽江千古情这个广告，丽江千古情就是一个舞台的表演剧，场景比较震撼展示了丽江的文化和历史等，如果自驾来这里这个表演不能错过,因为你可以了得到当地很多背景与文化。



晚上我们住的是丽江官方别墅花园酒店，这个酒店不错网上查了一下价格也不算很高值得推荐，酒店出门有公交到丽江古城，其实丽江的市中心和商业区是围绕古城修建的，所以酒店交通与商业区很近是很有优势的性价比也很高，以下是早上拍摄的酒店外景，我们第二天和第5天晚上都住在这家酒店。


第三天
第三天行程【长江第一湾-普达措国家森林公园-独克宗月光古城-《藏族土司宴舞》
早上8：00我们从丽江出发前往香格里拉，丽江平均海拔在2500米左右，香格里拉海拔大约是3400米左右，也就意味着高原反应会更加的严重，从丽江沿着金沙江前往香格里拉大约5小时，由于都是高海拔地区路上5小时导游不建议睡觉，也是因为这理由，一路导游都在滔滔不绝的为后续的购物埋下伏笔。
   早上出发大约中午到达香格里拉，貌似香格里拉有本地保护，外地导游是不能在这带团的，到当地换了本地的导游，香格里拉是藏区住了很多藏族同胞，在藏区女的叫卓玛男的叫扎西，换的导游是一位本地的卓玛，中午饭后先带我们去的当地的供氧站，因为香格里拉海拔比较高晚上睡觉时由于缺氧可能会导致不适应，所以建议这里多买两瓶氧气以备不时之需。
下一站前往普达措国家公园，普达措国家公园（位于滇西北“三江并流”世界自然遗产中心地带，由国际重要湿地碧塔海自然保护区和“三江并流”世界自然遗产哈巴片区之属都湖景区两部分构成，以碧塔海、属都湖和霞给藏族文化自然村为主要组成部分，也是香格里拉旅游的主要景点之一)。在普达措公园大约停留了接近4小时，以就是第三天的行程上午基本在路上，下午主要游览这公园，整体公园挺大的也很美是那种不加装饰原生的自然美，在城市待久偶尔来这地方零距离接触大日然感觉还是非常不错，进入公园后有几个景区，不同的景区通过电瓶车衔接内部是不让私家车进入，在电瓶车上的讲解员还特意介绍在不同的季节来这的感受都是不一样的，还介绍了湖南卫视主持人张杰谢娜的婚纱照就是在这里拍摄的，夸奖自己的同时不忘记用明星来再次确认他的说法，不过的确风景非常的美，这里除了山水远处还可以隐约看到雪山。
  

  

普达措国家公园游园结束后我们又来到了独克宗月光古城，时间大概是5点多了，我忽然发现云南的2月日落时间还是比较晚的大约7点后太阳才落下，所以5点多又前往了下一景点。
（来自百度百科：独克宗古城是中国保存得最好、最大的藏民居群，而且是茶马古道的枢纽。 位于云南省迪庆州香格里拉县的独克宗古城，是一座具有1300多年历史的古城，曾是雪域藏乡和滇域民族文化交流的窗口，川藏滇地区经济贸易的纽带。）到达独克宗古城给的游园时间不多，寺庙上有一个比较大的转经筒，转经筒又称“嘛呢”经筒、转经桶等，与八字真言和六字真言（六字大明咒）有关，藏传佛教认为，持颂六字真言越多，越表对佛的虔诚，可得脱轮回之苦。因此人们除口诵外，还制作“嘛呢”经筒，把“六字大明咒”经卷装于经筒内，用手摇转，藏族人民把经文放在转经筒里，每转动一次就相当于念颂经文一次，表示反复念诵着成百倍千倍的“六字大明咒”。有的还用水力、灯火热能，制作了水转嘛呢筒、灯转嘛呢筒，代人念诵“六字大明咒”。







在独克宗古城停留时间很短大约30分钟，我觉得景色挺漂亮的特别想了解藏传佛教文化的人不要错过这个地方。 离开独克宗古城后我们去吃晚餐，这里后续会介绍 。 香格里拉是高原对于我来说有比较小的反应主要是头有些不舒服，所以要多吸氧气，另外云南特别是香格里拉很干燥，导致我和老婆鼻子都不是很舒服，我对香格里拉感觉天很蓝人很少很多地方也在开发建设中，导游说再过几年来香格里拉就可以坐火车过来了相信那时会更好。

第四天
行程（“小布达拉宫”的心灵洗礼：香格里拉大理【葛丹松赞林寺-尼史村-虎跳峡-普陀泉SPA温泉度假村)
早上8：00出发前往香格里拉的葛丹松赞林寺，其实距离酒店非常近大约10分钟车程。(来自百度百科，在7-8世纪时，佛教开始传入迪庆地区，公元1678年，达赖喇嘛奏请康熙皇帝在中甸建立一座格鲁教派寺院。寺院于1679年破土动工，历时三年落成，是清康熙皇帝敕建的“十三林”之一。这就是葛丹松赞林寺的历史)。
云南与深圳有一些时差早上8点多的太阳有点像深圳6点多的感觉





远眺葛丹松赞林寺金色的鼎在太阳的照射下格外漂亮，从门口到寺庙上大约需要走50米左右的小路然后有100多阶的台阶，虔诚信佛的人要跪着从这里一直拜到寺庙上，小路两旁是僧人住的房间据说这时僧人们自己筹建善款修建。






寺庙里是禁止拍摄的外面可以拍摄，我开玩笑的说来到这里是否就不用再去西藏的布达拉宫了。寺庙中供奉了班禅与达赖的老师宗喀巴大师，开始我还不太了解班禅与达赖喇嘛的区别，后来我也百度了一下，班禅与达赖是同门的师兄弟它们区别：
达赖和班禅是是藏传佛教格鲁派（黄教）的两大活佛系统。西藏佛教界认为，达赖是“欣然僧佛”即观世音菩萨的化身；班禅是“月巴墨佛”即无量光佛的化身。历史上，清朝中央政权把达赖和班禅置于同等地位，分别由皇帝直接领导，他们都受清朝政府的册封。因此，达赖和班禅之间，互无隶属关系。
离开葛丹松赞林寺，我们来到了尼史村，这是当地藏族人居住的村庄，在旅游环节中有藏民家访，也就是说我们可以去藏族同胞的家里探访一下，看一下他们生活状态习俗与文化等 ，以下截图就是我们团即将拜访的藏族家庭

这种房子如果在深圳算得上是超级豪宅了，进入内部也非常的气派，可以看到内部大部分是木制结构，据说这全是自己家人雕刻制作的结果，在修建房子前他的家人回到山里找好大树，并伐树后搬迁到家附近在进行雕刻制作上漆最终呈现眼前的样子，具藏民说整个房子修建费用非常低很多材料都是木头制作的通过山里伐木就可以，当然现在为了保护环境伐木需要进行严格审批，不过现在也被禁止了，所以他们现在盖房子也会用砖或水泥来做反到成本高了很多。我感觉他们生活的现代化程度还是非常高的而且与城市无太大差别，唯独就是要解决经济来源，所以他们村也在对外开放搞旅游建设，这也是他们的生活主要来源，在搞旅游的同时他们非常喜欢银器也在搞银器加工出售，当然这个环节也就是带购物的，来时导游说藏民的东西是不会有假的，这点我比较相信，但是对比价格确实比较高，当时藏民说如果在这里消费，他们挣的钱一部分用于物品的成本，另一部分用于人员的开资还有一大部分会交到寺庙用户善款，他们每卖一件东西都会给他记公德分，所以希望大家多消费。

  

离开尼史村我们前往虎跳峡，这里我们也离开的香格里拉，虎跳峡相当于在玉龙雪山的背面，到达虎跳峡已经是下午了。
这里补充三点：
1.  香格里拉海拔3500左右离开香格里拉前往丽江与大理，丽江是2500大理是1800，所以后续就基本不需要氧气了，如果氧气有结余的话在香格里拉一定要用完。
2.  香格里拉到丽江的道路跑弯曲的高速路两边山石比较陡峭，特别下雨天途径这里还是比较危险的需要注意一些，以下截图是路两边拍摄，如果后续有自家游的同学需要注意，尽量避开雨季来这边。



3.从丽江到香格里拉手机信号变得非常差，4G信号肯定是没有的，2G信号也发不出去东西，香格里拉本地导游也说的这边信号是很差的，所以自驾游同学靠导航需要注意提前下载好本地地图否则信号不好，路上人又少如果问路语言再不通就很麻烦。
离开香格里拉前往大理整个路程估计要6小时多，途径虎跳峡大约从香格里拉出发到这里要3小时多，虎跳峡非常漂亮应该在玉龙雪山的西边方向，在虎跳峡往上看就是玉龙雪山。虎跳峡，以“险”名天下，是中国最深的峡谷之一，虎跳峡有香格里拉段和丽江段和之分。到达这里大约3点多停留大约1小时


我个人觉得虎跳峡这种自然风景还是非常漂亮的，峡谷两边很陡峭中央流淌着湍急的河水，现在人用现代的交通工具建设的公路都有很大的危险，何况以前，即便这样古人为了贸易流通再危险也无法阻挡他们，而这条路就是古代的茶马古道的毕竟之路，茶马古道是指存在于中国西南地区，以马帮为主要交通工具的民间国际商贸通道，是中国西南民族经济文化交流的走廊。用现代话说的更通俗就是现代的物流在云南与西藏内陆间卖茶叶所需要走的路。 导游说西藏高原蔬菜比较难生长所以很多藏人以肉为主食导致他们体内胆固醇比较高，茶叶特别是绿茶可以有效降低胆固醇，所以古代的西藏贵族对茶叶有着很旺盛的需求而绿茶时间长容易变坏不易保存所以需要在特定时间内把他们运到特定地方所以茶马古道因此由来，以下截图红框部分可以明显看到古人走茶马古道的足迹，还是非常的危险的 。


到晚上的19:00左右我们到达了大理的温泉酒店（普陀泉珍稀医疗热矿泉SPA温泉度假村）由于与很多温泉酒店很像这里就没有拍摄太多招聘也不做过多的介绍

第五天
行程【大理后江珠宝城-双廊奔驰Smart自驾OR双廊单车骑行-丽江同春珍宝】
第五天早上7点30从大理温泉酒店出发，因为今天有两处购物所以导游特意强调要7:30出发。购物环节统一介绍先跳过购物这里来介绍今天唯一一处景区大理洱海，在洱海有赠送项目Smart自驾OR双廊单车骑行（来自百度百科，洱海古代文献中曾称为叶榆泽、昆弥川、西洱河、西二河等，位于云南大理郊区，为云南省第二大淡水湖，洱海北起洱源，长约42.58公里，东西最大宽度9.0公里，湖面面积256.5平方公里，平均湖深10米，最大湖深达20米。洱海有两个出水口：1.在下关镇附近，经西洱河流出；2.“引洱入宾”。）洱海确实很漂亮在这里可以骑行与开smart路边有很多租车的，由于淡季也可以讲价钱，在洱海呆了1小时30分钟就返回丽江最后一个购物点了，关于洱海就介绍这些，风景确实很美自驾一定要来看看。

第六天
第六天是自由行，晚上9点飞机回深圳，18点旅行社会有人来接机。早上9点起床吃过早餐后前往丽江古城。以下截图是酒店对面的别墅，很漂亮感觉住的人不是很多，据了解这里的房子大约7千1平，200多平别墅大约200万+。

最后一天白天都基本在丽江古城了，建议找个古城比较高的位置的酒吧看看风景，听着音乐静下心来整理思绪，准备迎接工作。

最后一天比较累的原因，基本除吃饭买手信就待在酒吧了。晚上旅行团来接机的车也非常准时，这里说一下以下截图为丽江机场，丽江机场不是很大但确实很繁忙进去人很多，要知道当时可是淡季哦。
  
途经某城市夜景，非常漂亮。

---

#美食环节#
说完行程我们再来看看美食环节。 这里主要介绍丽江与香格里拉，正常我们行程去了三个地方，而在大理停留时间比较短也没吃太有特色的东西，所以只介绍丽江与香格里拉。在介绍之前先说一下团餐很一般，不要有太高的期望不过也可能是因人而异，只是我和老婆都不太喜欢吃而已,除团餐外自己找当地美食还是值得期待的，下面就来介绍一下。

首先来介绍一下丽江，在丽江吃美食找对地方性价比还是非常高的，这里不得不感谢大众点评与美团特别要感谢互联网，在这两个app里美食靠前的小店都非常不错，丽江推荐吃阿婆腊排骨、水性杨花（一种蔬菜名字）鸡丝凉粉和米线等。以下是在美团找的和叔食府的价格单。

两位吃了100多点也非常好吃，老婆是个吃货给这家的评价还很高，以下是一个大的烤鱼。

我印象中最深的是他家的酸奶非常好喝。

鸡丝凉粉


包浆豆腐

来云南米线不得不吃，以下是古城内找到 一家人比较多的米线。


强烈推荐的阿婆辣排骨和老婆来吃了两次，非常好吃而且还很便宜。阿婆辣排骨有很多店，我吃这样应该在古城的东北角，距离大水车东方向，这店是我和老婆打滴滴从酒店到古城过程中滴滴开车师本地人推荐的。阿婆腊排骨有点像我们吃火锅的感觉只不过盆比较小，其中辣排骨是限量的，蔬菜可以随便点这里也推荐吃一下水性杨花，挺好吃的应该是当地特有菜。


墙上挂满了腊排骨，据了解发霉越多的腊排骨越好吃。



香格里拉美食
香格里拉藏族人比较多，所以这里饮食也和民族特色有关，推荐酥油茶（偶尔吃一次还可以）。
和书油茶一起搅拌的奶 烤鸡肉
  

藏民火锅，其中肉包含了牦牛肉、羊肉和猪肉，可能是火锅的火比较小的原因，总感觉肉不是很熟吃着不是很习惯。


不过藏民们很热情，我们边吃边看他们演出，这个体验还是非常不错的。

---

#购物环节#
再来说一下购物环节，整个购物环节个人感觉比较压抑有点被强迫的感觉，如果不购物可不可以呢？ 我感觉厚着脸皮也是可以的，不过出来玩吗玩的就是心情不想被这种情况破坏了心情所以还是买了点，一同的团友也一样，不过这种旅游体验不管制未来只会导致口碑越来越差。本次行程旅游共分三次购物，一次在香格里拉由藏民卖的银器，一次在大理卖玉石和翡翠，最后一次在丽江黄龙玉。
首先说一下卖银器，这里导游推荐的并不多，估计拿的提层也比较少。银器主要是一些银碗、筷子和挂件等与丽江卖银器的地方比应该贵了一个数量级，不过个人感觉物品应该都是真的不会掺假。
然后再来说一下卖玉石与翡翠，导游一路都在以各种方式介绍这个，介绍方式如下：
1.爱心角度：路上放了多种视频，主要介绍云南很多比较穷的地方，孩子上不起学条件很艰苦，而游客在云南每一次消费都会帮助到这样的孩子，所以一定要多消费。
2.不要被遗忘：他介绍了老人总怕被人遗忘，所以老人会把一些贵重的物品转给后代，留作纪念防止被遗忘。所以岁数大的人一定要买一些贵重物品转给后代，防止被遗忘。
3.爱情角度： 导游举了个例子他曾经接待一位老板和老板的老婆，老板给老婆买翡翠时买个5万的，老婆嫌弃贵自己选了一个一万的。 回头老板又私下买了个5万的翡翠送给自己小三 ，以这案例来说女人就要买最贵的，不然钱全跑小三那了。
4. 文化角度： 翡翠与玉都是中国的传统文化，很多皇帝陵墓出土的都带有玉，这足以证明玉和翡翠文化的重要性。
5. 增值角度： 导游介绍,翡翠有价玉无价，现在大城市人都讲究投资，导游手上带了一个玉的戒子几年前买的，现在已经翻到了几万甚至更多，所以翡翠与玉有保值和增值等投资属性。
6.鬼神角度： 导游介绍男带观音女带佛、老板要请貔貅，保佑发财。说道貔貅这里补充一下： 貔貅说法有多种导游说的是，貔貅是龙的第九个儿子还是玉皇大帝的的宠物，嘴大吃的多，一次在玉皇大帝的坐位上拉了一坨屎，被玉皇大地拍了一下屁股把屁眼拍没了，所以貔貅只吃不拉寓意只进不出的意思。这里笔者百度了一下龙的九子分别是：
老大囚牛（qiúniú）
老二睚眦（yázì）
老三嘲风（cháofēng）
老四蒲牢（púláo）
老五狻猊（suānní）
老六赑屃（bìxì）
老七狴犴（bì’àn）
老八负屃（fùxì）
老九螭吻/鸱尾（chīwěn/chīwěi)
这里并没有貔貅，所以不同地方的说法真的不一样。
最后导游还说道，千万不要说你们没钱，你们出来玩的来自大城市到这里就是消费的。千万不要说玉器翡翠你不喜欢，里面有上万件商品一定有一件适合你。千万别进入玉石店就去上厕所，一上就1小时怎么屎尿那么多等，然人看不起。导游：我们服务你们这么多天，让你们开心，现在到（游客）回报的时候了。

大理的玉石和翡翠卖场，里面确实采用人盯人，也就是旅游团以家庭为单位进入玉石翡翠店后，有专门的服务为你这组家庭服务，同时每组家庭会有编号，买东西时需要出视编号，这购物店我们大约呆了3小时30分钟。不过我们团还好其中有一组家庭确实买了不少，估计整个行程花10万买了各种商品，所以团队消费达到了一定导游也没有再太多的为难我们。但是我也看到别的团，服务员在口气很不好的在推荐游客买东西。


丽江的黄龙玉卖场。由于上午在大理卖场待的时间比较长，大家都买了一些，所以到下午丽江的卖场已经是很晚了，我们也是最后一批团到达后卖场人非常少，估计待了能有1小时30分钟的样子就离开了，至此整个购物行程结束。最后，导游向游客标识感谢，并欢迎大家下次再来云南玩。

---

#总结#
1. 云南四季景色不一，但最好的季节还是5-10月，建议这时间去旅游。
2. 没有必要选择行程的观光点太多的团，譬如我们是走的丽江-> 香格里拉->大理->丽江 ，有的行程是昆明->丽江->香格里拉-> 大理 ，地方多反而更多时间都在路上，其实玩的也挺辛苦的。
3. 云南旅游分三种形式，纯玩团、自由行和带购物团。 依次推荐为自由行、纯玩团和带购物团。 我和老婆结束云南游后看新闻云南副省长也被强制消费了，所以这种压低团费强制消费的旅游模式确实不怎么好，而且我是在携程网上预定的团品质还是很一般，但云南是旅游大省，相信在未来会变的越来越好，只是短期有很大的上升空间。

    

以下是转自我同事(dorisbhwang)的一片文章，凤凰项目读后感在发此博客前我本人还没有看，但在看了她读后感后更有兴趣来读一读这本书。

---

凤凰涅槃，浴火重生
正文之前，一个职场老司机的困惑…..
作为一个在职场上混迹长达14年的老司机，从制造业的咨询顾问转变为互联网行业运维质量管理人员（QA）,对于我来说可谓是破釜沉舟，从零开始。理想是丰满的，现实是残酷的，投入到具体的运维质量管理工作后，发现我无法再以这么多年沉淀的方法论，以体系化、职业化的姿态来开展工作，尤其是对互联网行业运维体系的生疏，技术上的空白，简直就是致命的…
在困惑无助的瓶颈期，偶然机会运维界男神梁爷推荐看《凤凰项目》这本书，凤凰二字不禁让我想到了凤凰涅磐,浴火重生，自己此时需要的不就是重生吗？既然从零开始，放手一搏，学习吧！
言归正准，此书与各种介绍技术或方法论的书不同，以一个故事的形式讲述了一个IT项目从即将“流产“、IT运维部门面临被拆分的囧境到逐步的通过一系列举措取得项目成功并实现业务价值的过程，浅显易懂，结合自己曾经经历的“难产”的项目（广东电信管线投资管理系统建设项目、HW配置器项目、HW PIA项目），仿佛身临其境，触动了身体上的多根神经，将触动我的几点总结下：

1、  变更管理
提到“变更”，我为之色变，变更无处不在，毫不夸张的说，我曾经被“变更”伤的很深，这是个忧伤的往事，此处省去一万字…首先为愿意正视在变更上存在的问题，并且愿意去为改变这种现状做出努力的管理者或决策者致敬，书中IT运维总裁比尔如是乎，接任总裁一职后，意识到IT变更中的问题，马上对变更流程做了梳理，
采取了如下的措施：
1)  梳理什么是变更，明确变更的范围（这与我想做的工作不谋而合）
附书中定义：变更就是对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或虚拟操作，并且这样的操作可能对相关服务产生影响。
2)  执行变更审核流程，加大变更门槛，适当控制变更节奏；
说到这点，不得不提任何流程及工具的推行都会遇到各种阻碍，有些员工乃至管理者甚至可能认为引入流程阻碍了效率，如果再碰到了不好用的工具，那简直炸天了，所以引入流程和推行工具之前必须根据实际情况做深入的调研，多方面平衡，力求流程简化，工作易用，当然这事说起来容易，做起来难，也只能是智者见智了。
3)  变更可视化
做好变更记录，明确变更计划的制定者、变更对象、变更内容;
做好变更计划安排，发布审批通过的变更执行的日程表。
这一点其实没什么好说的，既定的工作如果都不做好安排，随着性子想怎么玩就怎么玩，活该你一天到晚忙到死，还没干成几件事情。
总之，我们避免不了变更，但我们要想办法避免紧急变更。
说到此处，我脑中呈现了一个变更管理的框架：

首先从业务层面要确定变更的痛点，想要如何管理，以上内容不需要面面俱到，可以根据痛点有重点的进行梳理，如果有条件，落地到工具中自然更好。

2、  工作类型梳理
记得我当初刚接手运维部门的QA工作之后，为深入了解运维工作，曾问过几个运维同事的日常工作分类和职责是什么，小伙伴们给的答案居然是含糊不清的，我不知道他们是真的不清楚，还是不善于总结说不出来，抑或是不想告诉我，囧…书中对IT运维部门的工作类型分为：业务项目、IT运维项目、变更及计划外的工作。人的精力是有限的，当各类工作一窝蜂的摆到眼前，谁也不能面面俱到，必要时必须要有取舍，确定不同时期的重心工作，正确的时间做正确的事情。结合实际的工作，身边运维同学对于业务项目和IT运维项目这两类一般能按照项目节奏按部就班的走，但一旦引入了变更和计划外的工作，往往会打乱既定的计划，承诺给业务部门的服务无法完成，所以工作的安排要留一定的buffer，以支持没完没了的变更和计划外的工作（如业务各种突发事件，各类运营系统的bug） 。希望这个工作类型的划分也能够触动身边运维同学的神经。

3、  开发运维模式下的实践
1)标准化
“IT工作不仅是无形的，因此更难追踪，而且可能出错的地方也要多得多。“
因此为了避免出错，需要更严格和守纪律，把运营环境标准化，并把这些标准应用于开发和运维的日常使用。写到这里，情不自禁叹口气，这是我目前的重点工作，曾经为这个目标迷茫过、困惑过，此书看完，坚定了我做运营标准化工作的决心。
2)持续优化
作为质量部过程改进中心的一员，持续优化天然是QA的职责，如何防止问题再次发生，一旦发生了问题如何更快的发现和修复问题，建立完善的问题管理机制的重要性由此可见。
3)营造一种工作文化
鼓励探索和尝试，从失败中吸取教训，反复实践，至于如何落实，我想是团队管理者仁者见仁智者见智了。  

4、  工作约束点
在书中，一个运维工程师是工作约束点，任何工作少了他都无法正常开展…我表示无语，居然会有这样的事发生！在我的经历中，某个人成为工作瓶颈的情况真不多见，不会说少了哪个人天能塌下来。我想团队分工、团队共享和人力储备这些是人员管理的根本吧（纯属个人意见）。 诚然，除了人这个因素，工作中会有各种障碍，反思下我们是否主动识别过约束点，如数据质量差、信息不同步、流程混乱等，识别到之后是否尝试去打破它？至于How，以后再深入学习探讨吧（偷个懒）。

Ok, 到这心得就完了，对于如何继续开展接下来的运营质量工作，我经历了从混沌状态到逐步清晰的过程，可谓是“凤凰浴火，涅槃重生”，路漫漫其修远兮，希望通过我的努力，能够看到质量上的不断的改进和优化，哪怕是一点点。

作者：研究僧
文章地址：http://blog.puppeter.com/read.php?52

项目时间：201603-201608

通常做项目标方向和理想是非常好的，但现实总有这样那样的问题，如以下截图。 所以引出本文在做项目中发现的一些问题：


开篇
      腾讯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开源。老板的一句话给我们带来更多的思考是如何去开源？ 而开源的前题也是如何更好的使用开源的工具在基础上有机会再开源，所以当时笔者也在想自己的业务上去寻找一些场景适合开源工具的解决方案。

Docker缘
    2014年什么最火，相信很多人会说是Docker ，它诞生于2013年，感觉它的诞生就是一鸣惊人且有不断蔓延趋势，国内很多技术分享也谈了很多Docker的发展趋势应用案例等。2014年底笔者接手了一些长尾业务，由于部门对机器低负载考核比较严格，所以当时也试着将一些高负载业务与低负载业务进行混合部署，混合部署、虚拟化是很多公司解决成本问题的一些手段，像网上经常看到Google很早之前就在用容器技术来实现业务间的混合部署， 当时公司也有很多BG以各种方式实现了不同业务间的混合部署，而由于SNG历史背景的原因很多业务还没有实现混合部署。笔者当时负责系统运营情况，在没有隔离情况下的这种混合部署方案并不好，因为高负载与低负载的业务混部在一起特别是晚高峰期一个大CPU毛刺就会影响到低负载业务从而导致线上投诉，所以在2014底和2015年初借鉴了其他BG的玩法，在部分场景下我们开始通过Docker来实现我们业务间的混合部署，实践证明这种混部要比前者更好，经过2015年一整年系统的开发与迭代初见规模，我们内部称呼为“琥珀离线系统”把高负载业务与低负载业务混部同时，也将高负载业务部署到了部门与公司的Buffer、数据库备机和低负载等资源上，如果业务使用Buffer资源系统，通过建设的系统能力可以将业务请求迅速的从Buffer上调走， 就这样我们把部分业务迁移到了Docker上。
   2015年下半年到2016上半年社交类业务出现了很多转码的需求，转码是用户从PC上传视频通过服务器进行格式与码率的转换在其他终端（ipad，手机）上都能看到，通过我们Docker + Buffer 、低负载形式再次解决了这类业务的需求，为部门解决了大量的成本，Docker离线再一次进入应用的小高峰。
  这时老板们也提出了更高的要求，是否可以实现在线的Docker化，毕竟离线底层用的是Buffer 、低负载资源是有一定天花板的，因为在海量运维中这些资源占比可能连10%都不到，2016年上半年我们开始做在线Docker研究。
   我们做了内部的研究与需求调研，在过程中也经过N轮的PK有人同意有人反对，记得有次一位同事说我们的运营效率可以在分分钟扩容千台机器，什么上Docker？
   答：因为，Docker宣称（Build， Ship and Run Any App， Anywhere!） 它通过镜像串联了开发的整个路径，并保障线上的一致性，你可以把镜像看作App，它可以运行在内部云和公有云上，方便业务以后在各种云上快速的拓展。
   同事：那织云（内部运营系统）在打磨一下也可以实现类似的这功能，为什么还要上Docker？
   答： 额。。。。
   其实当时笔者心里的想法是，是啊其实我们早实现这功能再稍改造就可以，但为什么火的不是腾讯SNG的织云而是Docker呢？ 值得思考。。。
   最终还是决定试探性的来用Docker管理在线服务，Docker这么火而且已经有成功的内部案例，但为什么是试探性这么没底气？
   开篇的时候讲过我们有很重的历史背景，在这种历史背景下没有最牛逼的工具，只有最适合我们的工具，很多创业公司把Docker玩得转因为没有任何历史的包袱，所以这里我们只能说是试探性来玩Docker，看它是否符合业务需求，还有另外还有一些原因：
          1. 刚的对话中已经说明了，内部运营系统早就支持了类似镜像功能，为什么还火的不是织云而是Docker ? 3分产品7分也运营，我想这也是Daocloud（Docker母公司）把Docker当作产品去做，所以这是我们值得学习的。
          2. 很多公司都在搞Docker，当一个新员工入职，你和他说织云，他会问什么是织云，但你说docker很多人会知道，所以不管什么技术，如果他能形成一套“协议”就会让彼此间更好的去沟通。
          3. 内部虚拟化也应用了Kvm，做弹性扩缩容Docker比Kvm更加的轻量级，在社交类业务中镜像有突发流量增长和计算的场景都很适合用Docker。
          4. 部门的运维的质量、效率、成本和安全都做的非常好，如果能以得分衡量应该是98分，但是对追求极致的我们需要的是100分，所以我们要关注开源产品、使用开源产品来寻找自研产品的不足
          5.  笔者曾经看过一篇文章《 为什么要探索宇宙》 文章大意（文章地址见参考）：
          1970年，赞比亚修女 Mary Jucunda 给 Ernst Stuhlinger 博士写了一封信，他因在火星之旅工程中的原创性研究，成为 NASA（美国航空航天局）Marshall 太空航行中心的科学副总监。信中，Mary Jucunda 修女问道：目前地球上还有这么多小孩子吃不上饭，他怎么能舍得为远在火星的项目花费数十亿美元。结论是探索宇宙可以带来相关产业的发展，太空探索就像一面人类审视自己的镜子，利远大于弊。
   相信探索在线Docker与为什么要探索宇宙是一样的，我们他做整个过程当作我们的镜子审视自己系统的不足，并推动改进。

探索在线Docker起航
     从中心下各组抽了一些热心同事，2016年4月份开工在线Docker。 作为运维最不好管控的就是时间前一秒在做项目，突然一个故障立即处理，处理完回过来忘记从哪开始做起刚有头绪又收到新的需求，所以我们需要一套管控手段来保证项目的目标与进度。首先，时间上每个人每天拿出30%来搞项目，其次我们引入了Scrum(敏捷开发框架) 来管理项目， 它的好处就是能在一段时间内，有一个共同目标，大家向着目标不断的跟进持续打磨，信息尽量的彼此间透明，最终保障短期目标与质量。
    前期很多事物在探索阶段整体看Scrum带来的收益还是不错的，我们发现了很多问题，这里有Docker本身问题、还有也有部门运营系统问题低层系统的问题，在线系统上线了300+ 容器运行过程中Docker本身并没有太大的问题。 一个小插曲一台母机上运行了多个容器，其中有的容器是测试机有的容器是在线服务器，某工程师登录测试容器修改了系统时间，由于Docker隔离型不是十分的好，导致整个母机时间都被更改影响各业务，这并不影响在线Docker持续探索，但也提醒我们如果拿整套在线Docker技术方案来做一个产品的化，我们需要一个产品的准入的规则，譬如小明家买了一个洗衣机，洗衣机对小明来说是一个产品，小明并没有看洗衣机的说明说就把衣服放入洗衣机，最终衣服大于洗衣机承载重量导致洗衣机的报废，同样在线Docker也需要一套说明书即准入规则、注意事项、测试过程中发现的问题、案例和潜在风险等，如果超出了准入规则的不准许接如，否则与洗衣机的结局是差不多的。
    运营了一段时间Scrum我们也发现了一些问题， Scrum可以解决一个小团队的问题，但我们需要依赖其他团队时从效率上看就没那么好了，如果Scrum两周为一周期，小团队在一周期内可以解决10件事，而涉及到依赖就只可能解决一件事，因为每个团队有自己的重点及KPI，遇到这种情况Scrum也是无能为力 。

小团队作战
      像Scrum应用中发现他解决不了的问题的案例，在一个大的公司中更多的讲究是团队作战群策群力一个需求来了后对他做需求分析，并拆分需求分给不同团队提升需求的效率和质量。每个部门，每个团队，每个人都是有KPI （关键绩效指标 ，英文全称 “Key Performance Indicator”），KPI的优势是不同环节认同一个目标并持续推进保证收益， 团队与团队之前的协作如果KPI是一致的那事情推进会非常顺利反之只能像Linux进程一样陷入中断状态。
      在这样背景下Scrum可以很好的解决小团队KPI目标、进度、质量，但与其他部门或组交集太多就无能为力了。在线Docker正是这样情况，当你申请其他团队资源时，在KPI的背景下首先被问的目标与收益是否明确，也正因为是探索型项目这些问题很容易被挑战，更多的时间在PK目标与收益。但要知道Google的GFS最初也只有三个人设计开发出来的，所以这种探索型产品前期需尽量少的人参与，与其他团队尽量的解耦 ，短期带来的问题可能是系统的重复建设，长期的收益是整个生态链质量的提升是值得的。笔者也在想Docker离线为什么会成功？ 原因也是开始团队比较小很多问题在内部可以很快的解决，时间上保障项目进度，同时也令大家的成就感更愿意去投入。

设立项目标及流程负责人
    经过一个月的试探，到5月底我们大概掌握了业务Docker在线相关系统的一些问题，解决问题同时也在并行实现Docker在线系统的产品化。 开始讲过参与Docker在线同学来自不同组，结合自己的业务大家从不同的视角希望Docker能带来更多的改善。其实大家的目标是一致的做Docker在线，但过抵达目标的过程却有很多分歧，有分歧是好事做一个产品如果连分歧都不没有就太没成就感了，但此项目就是分歧太多了且都有道理，怎么办？
   解决分歧更好的方式是拿案例来表明自己的想法正确的。PK案例：
   现有流程 ： 测试-> pkg (软件包管理系统) ->预发布 -> 线上系统
   改造流程:  测试机-> pkg ->预发布 （构建镜像机） -> 镜像仓库 -> 线上系统
   旧系统问题：历史原因导致 od未分离，开发可以任意登录线上系统导致系统配置不一致，当预发布环境有问题时，可以任意选择线上机器配置反录入到pkg系统再次发布，相当于给od为分离打了一个补丁。
   改造后流程 ： 预发布构建镜像后，由镜像保持整体链条环境一致性 。但历史原因导致我们的用户（运维/开发）习惯，扩容时是任意选择一台参考机来发布的，分歧就是改造后流程省略了选择这一步，而且首次选预发布机器后为了保障镜像里垃圾信息最少，后续不可以更改预发布机器， 有的同学就会疑问为什么不保持原有习惯？预发布机故障怎么办？ 就这样一个案例PK了多次，最终还是保持改造后的流程方案。
    PK是有必要的，但多次PK就会拉长战线和时间，再加上各种需求就会导致小团队每天很忙接需求，PK需求一段时间过去并没有什么起色，大家对项目的成就感也会打折。Docker在线项目成员来自不同的组，大家一起搞Docker在线形成了虚拟组，其实开始我们就忽略了虚拟组的技术负责，经常出现意见不一致开会PK没有结果再PK浪费时间的情况。有了技术负责人后，它来帮我们屏蔽不合理需求，当遇到问题不断PK时能及时站出给出方向加以解决，保障短期目标，同时提升大家项目中的成就感。
   每天晚上5:00大家都需要碰头沟通Docker在线的进度与问题，有意思的是经过一段时间大家都认为自己负责的环节已经OK了，但整体串联起来就有问题。我们分析了一下原因原来是这样，我们每个人负责的是在线Docker生产链上的一个环节如图1，一个在线Docker包含了多个环节，当自己负责的环节流程1没有问题也就确认自己是没有问题的，结合之前的结果看并没有什么问题。 但成功并仅仅需要自己的成功还要确保自己下游、下游的下游全部成功才可以，所以需要每个人对系统的流程负责，当自己的环节或自己下游环节出现问题需要主动把问题抛出来，同时尽快推进问题的解决。

图1，生产链

用数据来证明
     5-6月底我们通过运营系统在逐步小规模上量验证Docker玩法的可行性，但是随着时间推移发现量并没有快速的上升，原因是资源有限每天在串行的上量，系统的扩容流程一旦发生问题只能停滞待问题解决后再继续。开始感觉经过一段时间量没有上去，没有上去的原因自己也说不清楚，所以当时一直在思考为什么自己也说不清楚，因为流程不稳定错误每天都在发生，每天发生完当时解决完就完了，没有沉淀数据也看不到全局数据能看到哪里的问题比较多。 邮件是一个很好的工具针对这种情况，我们沉淀了所有的日问题数据，并在每周5进行分类汇总，对分类后的结果进行排序，并根据排序的原因设定负责人推进。 经过一段时间数据的沉淀大概能分析出一些问题主要分两类：
1. 运营系统设计的目标和准入标准
     1.1 部门之前一直在提一键运维，从这个目标上看运营系统确实已经达到了，但Docker的扩缩容目标更多的是无人值守运维，目标显然是与目前项目不契合的导致在上量过程中遇到了很多问题。
     1.2 我们运营系统设计过程中的一个重要环节借鉴了Unix设计哲学中的思路，即一切接文件，通过管道来串联文件的输入和输出关系，这也说的是我们运营系统中的流程系统。由于历史原因导致流程系统的环节很长通常扩容一批机器需要16+以上步骤，而流程长就会间接导致成功率的低，从Docker小规模上量过程中期表象更多是运营系统的问题因为他直接暴露给用户，但实际更多是后端错综复杂的逻辑没有接入标准导致流程系统的不稳定。在一个大的系统中需要保证自己成功率的同时，依赖系统也要有严格的准入标准，并通过数据来找出问题，设定责任人并推进优化改善，同时尽量的减少流程环节。
2. 是业务符合架构还是架构符合业务
    笔者时常在思考这个问题，有意思的是笔者在部门中两个角色都做，相信站在不同的角度的答案也是不一样的，笔者之前做过业务所以站在业务的角度希望更多的是架构来符合业务，因为部门负责业务产品比较多每个产品都有快速发展的时候，如果跟不上发展将会被淘汰所以更希望架构来符合业务，实际上从运营系统发展历程上也能看到很多历史的影子 。 而目前笔者从事的是架构，更多希望是业务来符合架构，原因是在实际运营过程中发现运营系统和架构在符合各自产品标准上已经慢慢没有了自己的标准，导致系统臃肿与效率的下降， 另外很多人已经习惯了这种架构符合业务的方式，而最难改变的就是用户习惯，我们能做到的只能是增加架构与业务间彼此沟通，制定架构的准入标准，尽量满足业务的需求，并持续的完善与迭代。这里有一个模式可以借鉴就是微软的windows系列，推翻老的系统不断的更新操作系统的大版本，在实际运营过程中，发现问题再打补丁，同时系统尽量向下兼容，满足客户的需要。

end..

---

参考文章
1）Docker历史　http://www.oschina.net/news/57838/docker-dotcloud
2） 为什么要探索宇宙 https://www.douban.com/note/321442729/
3）Google 全球研发总监访谈 http://news.cnblogs.com/n/542090/

北京工作时在中关村地下广场学的成人钢琴，可惜当时就录制了一个视频。

经常看到网上有人说把一个重要的文件删除了，而恢复成本很高，所以一直在想Linux终端中为什么没有像Windows下的回收站这样的设计，直到看到Unix编程艺术上的一段解释。 其实，Linux世袭了Unix的设计理念与传统，而Unix本身并没有这样的设计并延续到了Linux。

Unix面向更加专业的用户 ,Unix的开发者喜欢清晰、简单的操作，用户告诉做什么就做什么，即便用户使用的命令等价于“向我开枪”的命令。而这样做Unix的开发本能辩解的就是：保护用户避免自我损害，应该是GUI或应用程序级别的事，而非操作系统:)。

这就解释了Linux终端为什么没有类似Windows回收站的设计，当然我们也可以通过Shell方式自己来实现一个类似回收站的功能，以下是笔者在2007年与2008年时写的shell回收站，供参考：
1.第一版本（http://bbs.chinaunix.net/thread-1034672-1-1.html）
2. 第二版本http://m.blog.chinaunix.net/uid-7176662-id-2068124.html）

第二版本原始链接已经找不到了，在网上搜索半天才找到，估计是CU数据迁移时导致丢失，所以为防止再次丢失把版本二贴到本博客一份。