博客园_amen 专注于 .NET B/S

云计算风险识别

2010-12-06T07:25:00Z

云计算风险识别

一 Policy and organizational risks（政策和组织风险）

1）Lock-in （锁定，服务锁定无替代者）

2）Loss of governance （失去治理）

3）Compliance challenges（合规挑战）

4）Loss of business reputation due to co-tenant activities（由于共享活动而导致的商业信誉损失）

5）Cloud service termination or failure（云服务终止或失败）

6）Cloud provider acquisition （云服务提供者的获得）

7）Supply chain failure（供应链断裂）

二 Technical risks （技术风险）

1）Resource exhaustion (under or over provisioning) （资源枯竭）

2）Isolation failure （孤立）

3）Cloud provider malicious insider - abuse of high privilege roles（云供应商的内部恶意攻击者——滥用特权）

4）Management interface compromise (manipulation, availability of infrastructure）（管理界面的危害——基础设施可获得性，操纵）

5）Intercepting data in transit（传输中的数据截取）

6）Data leakage on up/download, intra-cloud（数据泄漏）

7）Insecure or ineffective deletion of data （不安全的或无效的数据删除）

8）Distributed denial of service (DDoS 分布式拒绝服务攻击)

9）Economic denial of service (EDOS经济拒绝服务)

10)Loss of encryption keys（密钥丢失）

11)Undertaking malicious probes or scans（进行恶意探测或扫描）

12)Compromise service engine （危害服务引擎）

13)Conflicts between customer hardening procedures and cloud environment（客户强化程序与云环境之间的冲突）

三 Legal risks（法律风险）

1）Subpoena and e-discovery

2）Risk from changes of jurisdiction（管辖变更风险）

3）Data protection risks （数据保护风险）

4）Licensing risks（许可风险）

四 Risks not specific to the cloud（非云服务特定风险）

1）Network breaks（网络中断）

2）Network management (ie, network congestion / mis-connection / non-optimal use) （网络管理）

3）Modifying network traffic（网络流量变化）

4）Privilege escalation（权限扩大）

5）Social engineering attacks (ie, impersonation)（社会工程攻击）

6）Loss or compromise of operational logs（丢失或泄漏操作日志）

7）Loss or compromise of security logs (manipulation of forensic investigation)（修饰或泄漏安全日志）

8）Backups lost, stolen（备份丢失、被盗）

9）Unauthorized access to premises (including physical access to machines and other facilities)（未授权访问）

10）Theft of computer equipment （计算机设备失窃）

11）Natural disasters（自然灾害）

本文链接

五年之痒

2010-07-15T08:10:00Z

在收到了公司人力资源的续约邮件后，我才明确的意识到了，我来此公司已经整整5年了。邮件的主要内容是告诉我5年合同期已满，需要续约，当然，公司是愿意与我续订的（续五年）。当然，我早就知道这是我的第五个年头了，甚至是五年前，我就知道2010年会是我的第五个年头（呵呵，废话）。

现在听着12年前曾经很喜欢的Beyond 的专辑《这里，那里》，写着这篇日志，用这安静的一小段时间，回忆着不算平静的五年工作与生活。 5年说长也不长，说短也不短，其实整个职业生涯也不过6个5年而已。还清晰的记得5年前，哥哥亲手帮我把行李箱扛上北上的火车，送我离开武汉。陌生的北方，有点失望的小城市——ZZ，5年前我坐的917路车还依然运行如往。

第一年（2005.7-2006.6）：新疆实习，认识了一些朋友，但几乎是荒废了一年时间……，生活比较丰富。（结识XM）

第二年(2006.7-2007.6)：事实上的职业生涯第一年，开始努力工作，对未来的工作满怀信心。在这一年里，几乎独立承担了一个项目（没人愿意干的烂项目，我一人干），压力挺大，不过最后结果是圆满的。得到了领导和身边同事的认可。生活有些寂寞~（认识贝贝）

第三年(2007.7-2008.6)：有了明确的生涯规划与目标。努力学习，知识增长较快，工作也算上手了。年底被评为公司优秀员工。生活开始不寂寞~（了解BOBO）

第四年（2008.7-2009.6）：三年也痒，这个时候开始有些不满目前的工作状况了，开始有些其他的想法了。后来毅然决然的出走北京。这一年结婚了~（媳妇很好）

第五年（2009.7-2010.6）：感到从没有的无奈和无聊。换项目，换部门，也没有找到合适的位置……。生活开始不平静了~（宝宝今年面世）

当然这几年中还有很多事情发生，比如“玻璃门”，“贝贝离职”，“BOBO南下”，“ZZ事业部倒台”，就不一一详述了，有兴趣的可以翻阅我的其他日志。

有人推荐《毕业五年决定你的一生》这本书，看题目貌似很符合你我，可我没兴趣，因为太没谱，看了也无益，还不如看《两宋风云》更有趣呢。因为这个题目完全是危言耸听了。不过在这5年里，我总结了一些有趣的规律：和我一起并肩战斗的同事，很多已经不在我依然还在并且准备继续待下去的公司（当然，我也愿意继续与公司签5年）。比如最早的贝贝，后来的BOBO和DX，到目前的LW（原谅我，就提到一下这个人吧），都是与我有密切合作的同事，所以他们都被我“方”走了(当然还是有一些没走的，比如：lb，DG，cl，lhf)；第一年被评为优秀，第二年评为良好，第三年评为合格，第四年……，这里的规律就是“王小二过年，一年不如一年”。

国企其实挺好玩，5年合同期满了，你不必有任何忧虑，Ta必然不经过与你的任何沟通，继续与你续签的。不过绝大多数的人都是愿意续约的（原因你我都深有体会的）。不过，我其实从最开始，直到目前还是最羡慕公平、开放、富有激情的外企（此生不知还会有机会没）。

好了，就到这里吧，这就是我的5年之痒，希望下个5年能精彩一些吧。

本文链接

敏捷软件开发

2010-06-16T09:03:00Z

人与人之间的交互是复杂的，并且其效果从来都是难以预期的，但却是工作中最重要的方面。

-- Tom DeMacro、 Timothy Lister

一、简介

概念：敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷软件开发宣言：

个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划

虽然右项也有价值，但是我们认为左项具有更大的价值。

敏捷软件开发有很多不同的实践和形式，它包含很多具体的方法论比如极限编程（XP），Crystal和Scrum，当然并不局限于这些方法论。其中大多数方法特点类似，采用增量迭代式的方法来计划、开发和部署软件项目。每个方法论均依靠反馈，提高软件项目的透明度，来发现那些通常易被个别人忽略或遗漏的问题。些额外提供的信息，可以让每个人都能更早做出更好、更明智的决定，从而能够适应不断产生的变化，并进行优先级调整。敏捷方法论的一个重要特点是需向客户频繁发布项目结果。发布时机尚未成熟，至少还可以提供可演示并且具备发布潜力的软件。

采用敏捷实践并不神秘。它只是尽力更快、更早交付价值的一种方式。敏捷方法的根基在于，它鼓励尽量先为客户交付系统中最具价值的部分。不同的实践让团队能够在保证质量的前提下完成任务。

终端用户不需要苦等整套系统全部开发完成，他们就可以从最具价值的部分提前获益了。为了达到这样的目的，敏捷专注于通过纪律性的工作方式提高沟通质量，增加从持续反馈中学习的机会，并且减少不必要的例行公事所带来的麻烦。举个例子，持续回顾将在整个项目周期里反复进行，以让团队仔细思考并且持续的调整他们的开发流程，以符合开发的具体场景。

二、敏捷软件开发要素

图：敏捷开发模型

上图两个圆圈表示不同的视角上的敏捷实践，包括开发者视角和项目管理的视角。接下来从里向外进行介绍。

Test-Driven Development（测试驱动开发）：它是敏捷开发的最重要的部分。在ThoughtWorks，实现任何一个功能都是从测试开始，首先对业务需求进行分析，分解为一个一个的Story，记录在Story Card上。然后两个人同时坐在电脑前面，一个人依照Story，从业务需求的角度来编写测试代码，另一个人看着他并且进行思考，如果有不同的意见就会提出来进行讨论，直到达成共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘，编写该测试代码的实现。如果没有测试代码，就不能编写功能的实现代码。先写测试代码，能够让开发人员明确目标，就是让测试通过。

Continuous Integration（持续集成）：在以往的软件开发过程中，集成是一件很痛苦的事情，通常很长时间才会做一次集成，这样的话，会引发很多问题，比如build未通过或者单元测试失败。敏捷开发中提倡持续集成，一天之内集成十几次甚至几十次，如此频繁的集成能尽量减少冲突，由于集成很频繁，每一次集成的改变也很少，即使集成失败也容易定位错误。一次集成要做哪些事情呢？它至少包括：获得所有源代码；编译源代码；运行所有测试，包括单元测试、功能测试等；确认编译和测试是否通过，最后发送报告。当然也会做一些其它的任务，比如说代码分析、测试覆盖率分析等等。在我们公司里，开发人员的桌上有一个火山灯用来标志集成的状态，如果是黄灯，表示正在集成；如果是绿灯，表示上一次集成通过，开发人员在这时候获得的代码是可用而可靠的；如果显示为红灯，就要小心了，上一次集成未通过，需要尽快定位失败原因从而让灯变绿。

Refactoring（重构）：相信大家对它都很熟悉了，有很多很多的书用来介绍重构，最著名的是Martin的《重构》，Joshua的《从重构到模式》等。重构是在不改变系统外部行为下，对内部结构进行整理优化，使得代码尽量简单、优美、可扩展。在以往开发中，通常是在有需求过来，现在的系统架构不容易实现，从而对原有系统进行重构；或者在开发过程中有剩余时间了，对现在代码进行重构整理。但是在敏捷开发中，重构贯穿于整个开发流程，每一次开发者check in代码之前，都要对所写代码进行重构，让代码达到clean code that works。值得注意的是，在重构时，每一次改变要尽可能小，用单元测试来保证重构是否引起冲突，并且不只是对实现代码进行重构，如果测试代码中有重复，也要对它进行重构。

Pair-Programming（结对编程）：在敏捷开发中，做任何事情都是Pair的，包括分析、写测试、写实现代码或者重构。Pair做事有很多好处，两个人在一起探讨很容易产生思想的火花，也不容易走上偏路。在我们公司，还有很多事都是Pair来做，比如Pair学习，Pair翻译，Pair做PPT，关于这个话题，钱钱同学有一篇很有名的文章对它进行介绍，名为Pair Programming (结对编程)。

Stand up（站立会议）：每天早上，项目组的所有成员都会站立进行一次会议，由于是站立的，所以时间不会很长，一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等，而是每个人都回答三个问题：1. 你昨天做了什么？2. 你今天要做什么？ 3. 你遇到了哪些困难？站立会议让团队进行交流，彼此相互熟悉工作内容，如果有人曾经遇到过和你类似的问题，那么在站立会议后，他就会和你进行讨论。

Frequent Releases（小版本发布）：在敏捷开发中，不会出现这种情况，拿到需求以后就闭门造车，直到最后才将产品交付给客户，而是尽量多的产品发布，一般以周、月为单位。这样，客户每隔一段时间就会拿到发布的产品进行试用，而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁，每一个版本新增的功能简单，不需要复杂的设计，这样文档和设计就在很大程度上简化了。又因为简单设计，没有复杂的架构，所以客户有新的需求或者需求进行变动，也能很快的适应。

Minimal Documentation（较少的文档）：其实敏捷开发中并不是没有文档，而是有大量的文档，即测试。这些测试代码真实的反应了客户的需求以及系统API的用法，如果有新人加入团队，最快的熟悉项目的方法就是给他看测试代码，而比一边看着文档一边进行debug要高效。如果用书面文档或者注释，某天代码变化了，需要对这些文档进行更新。一旦忘记更新文档，就会出现代码和文档不匹配的情况，这更加会让人迷惑。而在敏捷中并不会出现，因为只有测试变化了，代码才会变化，测试是真实反应代码的。这时有人会问：代码不写注释行吗？一般来说好的代码不是需要大量的注释吗？其实简单可读的代码才是好的代码，既然简单可读了，别人一看就能够看懂，这时候根本不需要对代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂，就表示设计还不够简单，需要对它进行重构。

Collaborative Focus（以合作为中心）：表现为代码共享。在敏捷开发中，代码是归团队所有而不是哪些模块的代码属于哪些人，每个人都有权利获得系统任何一部分的代码然后修改它，如果有人看到某些代码不爽的话，那他能够对这部分代码重构而不需要征求代码作者的同意，很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码，即使团队的人员变动，也没有风险。

Customer Engagement （现场客户）。敏捷开发中，客户是与开发团队一起工作的，团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后，能够以最快速度得到客户的反馈。

Automated Testing （自动化测试）：为了减小人力或者重复劳动，所有的测试包括单元测试、功能测试或集成测试等都是自动化的，这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具，能够编写自动化测试脚本或者用工具录制。

Adaptive Planning（可调整计划）：敏捷开发中计划是可调整的，并不是像以往的开发过程中，需求分析->概要设计->详细设计->开发->测试->交付，每一个阶段都是有计划的进行，一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代，小版本的发布，根据客户反馈随时作出相应的调整和变化。

三、敏捷开发与传统开发模式（瀑布模型）式对比

	敏捷开发	传统开发
需求	复杂多变、非典型、不确定	需求确定、传统行业
计划	可调整	严格计划
开发周期	较短	较长
文档	崇尚较少文档	文档齐全
人	对开发人员素质要求较高	要求不高
项目规模	适合较小团队（100人以下）	没有限制
规范	可能不符合CMMI	能适应CMMI规范

从上表可看出，敏捷开发较适合需求不是很明确，或者非典型的开发项目。而在传统的瀑布模型开发里，使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。这样导致流程繁琐，对需求变更的响应慢；而敏捷的核心是迭代，其终目标是让客户满意，所以能够主动接受需求变更，这就使设计出来的软件有灵活性，可扩展性。

四、敏捷团队建设

在公司一个典型的敏捷团队中，大致有四种不同角色：项目经理、业务分析师、开发工程师、测试工程师。同时，根据项目不同可能还需要：美术设计师、数据库工程师、系统工程师、交互设计师等不同人员。虽然在项目中不同的人需要确定一个角色，并担负相应的责任，但在公司内部，人与人之间是完全平等没有级别区分的。这种平等的文化，就使得人与人之间的交流不会因为等级差距而丧失。同时公司鼓励每个人向其感兴趣的其他领域发展，成为综合性人才。例如某个人现在是开发人员，但他也可以通过帮助项目经理做一些辅助工作，来学习项目管理方法，从而最终成为独当一面的项目经理。

项目成功的一个重要因素就是交流。保障团队内外顺利交流是项目经理的责任之一。公司鼓励员工之间交流看法和讨论问题。在公司内部，如果有闲暇时间，随时可安排一场讲座。这些讲座都是由员工自发组织和自愿开展，话题多种多样，不仅仅限于技术。经济、法律、业务知识等等，都是大家平时感兴趣的领域。在项目中，定期的Learning Lunch也是公司项目的一大特色。和客户一起围坐在餐桌前，边享受公司提供的午餐边讨论项目中的技术，团队的学习交流气氛自然会无限高涨。

除了自发的、自由的交流，还有一些约定的交流时间和形式，例如，每天的站立会议。你要说出昨天做了些什么，今天会做些什么，遇到了什么困难是否需要别人的帮助。站立会议鼓励每个人说出事情的真相。有了困难就大胆的向你最值得信任的同伴来寻求帮助，没有人会嘲笑你，也没有人会冷漠的不去理睬你的困境。一个自组织的团队，应当是一个温馨而又和谐的集体。每个人都会努力的帮助其他的人，帮他解决他的问题并从中积累更多的经验。

无论是在项目中还是在个人的发展过程中，回顾与总结都是一个必不可缺的步骤。公司内部任何事情告一段落的时候都会有一个总结活动。迭代总结，项目总结，发布总结，陪训总结等。在这段时间内什么做的好，什么做的不好，如何进行改进。任何的过程和成绩都不能是静止不变的。只有不断的反省和总结，才能够在未来的发展中进一步提高。项目团队一起召开总结会议活动，在这个活动中，任何人不能够对其他人进行指责和攻击，一切都应该以互相信任为基础，我们的目的是提高下次的工作效率和增强同伴的信心，而不是批斗和推卸责任。公司对员工的绩效考核，也是类似的由一起工作过的同伴来进行评价，360度全方位考核。这种定期的总结和回顾，提供给了员工与团队自我成长的机会。

除了内部的交流，公司还鼓励员工进行技术创新和参与其他社会活动，例如参与开源软件开发、撰写书籍、向杂志投稿、参加和举办技术社群活动等。这些对技术社区的贡献，不仅仅能够提高员工个人的能力，同时还展现了公司员工的整体能力和提升了公司的知名度。对公司和个人来说是双赢。

公司采用大长桌作为开发用桌。座位之间没有隔板。一方面适合与敏捷开发中的结对编程实践，另一方面可以减少隔板带来的交流障碍。如果你到一个采用隔板的公司去走一圈，再来比较公司的工作环境，就会明显的感受到交流频度和广度的明显不同。公司提供给开发人员舒适的座椅，带有扶手并可以调节高度和后仰角度，以适合每个人不同的需要。如果中午工作累了，还可以躺在椅子上小憩一会养足精神以便下午更好的投入到工作中。

在项目中，必不可缺的交流工具是白板和纸。再没有比这更廉价和更好用的工具了。两个开发人员遇到了分歧，两人走到白板前写写画画，很快，一副清晰的系统脉络就出现在两人面前。分歧达成了一致，开发继续进行，而图像留在白板上，任何过路的程序员都可以驻足观看，如果感兴趣还可以问一问作者，更深入的探讨。在开发的过程中，随时遇到问题或需要记录的，都可以立即写在手头的白纸上，一些简单的算法草稿，也都是用白纸完成。这些白纸多是打印用过一面的纸张，环保而又经济。

附1敏捷开发工具：

敏捷开发工具（.Net）

NUnit――单元测试。
NAnt――build工具
NDoc――文档生成。
CruiseControl.Net ――持续集成。
MS TFS——团队协作

敏捷开发工具(Java)

Ant——build工具
Junit——单元测试
JavaDoc——文档生成
CruiseControl——持续集成
IBM Jazz——团队协作

附2 图书与网站：

敏捷软件开发:原则、模式与实践（Agile Software Development, Principles, Patterns, and Practices ）原出版社： Prentice Hall 出版社：人民邮电出版社作者： (美)Robert C. Martin

高效程序员的45个习惯：敏捷开发修炼之道人民邮电出版社作者：(美)Venkat Subramaniam Andy Hunt 译者：钱安川、郑柯

构筑敏捷的开发团队：微软Visual Studio 2010实战兵法 电子工业出版社作者：高阳、蒋建华、毛志勇、段君毅

企业应用架构模式 作者：（美）福勒著出版社：人民邮电出版社

敏捷开发的艺术(The Art of Agile Development) 原出版社： O'Reilly Media, Inc. 出版社：机械工业出版社作者： James Shore 、Shane Warden 译者：王江平

卓有成效的程序员（The Productive Programmer）原出版社： O'Reilly Media, Inc 作者： (美)Neal Ford 译者：Thoughtworks中国公司

软件开发沉思录--ThoughtWorks文集（The ThoughtWorks Anthology: Essays on Software Technology and Innovation）原出版社： Pragmatic Bookshelf 出版社：人民邮电出版社作者： ThoughtWorks公司译者： ThoughtWorks中国公司

http://www.thoughtworks.com/cn/ ThoughtWorks中国公司

http://www.infoq.com/cn InfoQ

http://www.martinfowler.com/ Martin Fowler，ThoughtWorks的首席科学家，当今世界软件开发领域最具影响力的五位大师之一

http://blog.nona.name/ 李默，ThoughtWorks公司高级咨询师、业务分析师

http://www.cnblogs.com/DesignPatterns/ 肖鹏，ThoughtWorks中国公司咨询师

http://gigix.thoughtworkers.org/ 熊节，ThoughtWorks中国公司咨询师

本文链接

嫁给程序员吧!!!

2009-10-25T12:07:00Z

1. 专一的心，除了计算机就是你！ 2. 不喝酒不发脾气！ 3. 一套衣服穿半年! 4. 没时间接触其它Girl，想搞婚外恋也没可能。 5. 平时总加班. 6. 只认识0和1，基本没理财能力，一定会主动把所有的钱都交给老婆管，还会千恩万谢地。 7. 知道既然世界上不存在没有Bug的程序，就更加不会有没有缺点的人，所以绝不会老婆太过苛求。 8. 知道系统若不经常维护就无法保持稳定运行，所以一定会每天...

Cute Editor for .NET v6.4

2009-09-03T10:00:00Z

控件名称：Cute Editor for .NET v6.4官方网站：http://cutesoft.net/官方下载：http://cutesoft.net/Downloads/最近更新日期：2009年8月23日（星期三）说明：.NET平台最强大的所见即所得HTML编辑器（The most powerful WYSIWYG browser-based Online HTML Editor for...

Java与.NET的WebServices相互调用

2009-06-23T10:05:00Z

一:简介本文介绍了Java与.NET开发的Web Services相互调用的技术。本文包括两个部分，第一部分介绍了如何用.NET做客户端调用Java写的Web Services,第二部分介绍了如何用Java做客户端调用.NET开发的Web Services。　二:项目需要的工具　　WindowsXP Professial(IIS)Eclipse3.1(已装好Tomcat axis) VS.Ne...

用户体验5大要素

2009-06-19T01:51:00Z

自下而上的建设表现层（Surface）是看到的一序列网页，由图片和文字组成。关注的是视觉设计（Visual Design），也可以说是最终产品的外观。框架层（Skeleton）按钮、表格、照片和文本区域的位置，用于优化设计布局，以到达这些元素的最大效果和效率。被分成3个部分，必须完成信息设计（Information Design）促进理解信息表达方式；还包含界面设计（Interface Desi...

【转】LINQ To XML 入门(3)

2009-04-23T02:50:00Z

Some Common Operations using LINQ To XML - Part IIIIn this article, we will explore some common ‘How Do I’ kind of examples using LINQ to XML. This article is the final part of our 3-part ...

【转】LINQ To XML 入门(2)

2009-04-23T02:49:00Z

Some Common Operations using LINQ To XML - Part IIIn this article, we will explore some common ‘How Do I’ kind of examples using LINQ to XML. This article is the Part II of the 3-part LINQ...

【转】LINQ To XML 入门(1)

2009-04-23T00:33:00Z

Some Common Operations using LINQ To XML - Part IIn this article, we will explore some common ‘How Do I’ kind of examples using LINQ to XML. This article is the Part I of the 3-part LINQ t...