云计算风险识别
一 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（自然灾害）
人与人之间的交互是复杂的，并且其效果从来都是难以预期的，但却是工作中最重要的方面。
-- 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中国公司咨询师
1. 专一的心，除了计算机就是你！
2. 不喝酒不发脾气！
3. 一套衣服穿半年!
4. 没时间接触其它Girl，想搞婚外恋也没可能。
5. 平时总加班.
6. 只认识0和1，基本没理财能力，一定会主动把所有的钱都交给老婆管，还会千恩万谢地。
7. 知道既然世界上不存在没有Bug的程序，就更加不会有没有缺点的人，所以绝不会老婆太过苛求。
8. 知道系统若不经常维护就无法保持稳定运行，所以一定会每天都对老婆精心呵护。
9. 会帮老婆把菜谱改写成if...then...do while的格式，并且带有漂亮的缩进。
10. 老婆可以对所有的表弟、表妹宣称：“你们的毕业设计我全包了……”
11. 老婆的QQ不好用了，急得不行。程序员会从容地说：“没事，交给我吧”，然后祭出SoftIce、WinDbg、VisualStidio 20XX调试3小时，最后搞到系统崩溃，重装了事。
12. 如果将来小孩不爱学习，老婆就可以教育他说：“再不用功，将来就会像你老爹那样，只能作程序员……”
13. 如果将来小孩沉迷网游，老婆就可以埋汰他说：“你还在玩你老爸在厕所里憋出来的那个破游戏呐？”
14. 如果将来小孩嫌背单词太枯燥，老婆就可以把程序员的代码拿给他看：“看你老爹为了背单词，重复了多少遍if else for 和 string啊？！”
15. 嫁给瘦弱的程序员，也许永远无法目睹他像李连杰那样以一敌十的英姿，却也会听到他吼道：“哪个孙子又在QQ上骂你呐？看我不盗了她的号……”
16. 嫁给程序员，也许一辈子没机会开奔驰、坐宝马，却也会听见他在梦中叹道：“要是奔驰宝马也能盗版就好了……”
17. 对色彩和流行毫无感觉。所以当老婆从试衣间里走出来的时候，他会故作沉思状地摸摸下巴，然后随机从数组["很可爱","显得你更高挑了","显得你更文雅了","哇，好性感！","好像不太适合你这么瘦的女孩子","好清纯！","这颜色最适合你这样皮肤好的女孩子了","天哪，穿在你身上就是不一样！"]中选择一个Item。
18. 除了每个月买一本书，就没有其它需要花钱的地方，剩下的钱只能变着法的给老婆买各种首饰和衣服。
19. 每天都读书到深夜，是孩子的好榜样。
20. 每天都被Bug和客户双重折磨，有极好的耐心和涵养，就算跟老婆吵架也能保持温柔和冷静，不太可能说出不理智的话伤了老婆的心。
控件名称：Cute Editor for .NET v6.4
官方网站：http://cutesoft.net/
官方下载：http://cutesoft.net/Downloads/
最近更新日期：
说明：.NET平台最强大的所见即所得HTML编辑器（The most powerful WYSIWYG browser-based Online HTML Editor for ASP.NET）博客园也有用到此编辑器(好像已经是新版本了)。国内见得最多的版本目前是v6.0。新版本6.4不仅继承原有功能，而且增加了很多实用功能，并且很好的支持IE6，IE7，IE8，和Firefox3.5 等主流浏览器，依然提供.NET FrameWork 1.1和2.0两种版本（即涵盖1.1——3.5所有版本），并且国际化做得比以前的版本更完善（提供约30种不同语言）。
部署步骤（基本不变，.NET1.1和2.0版本部署基本一致）：
1. 安装CuteEditor assembly 文件和license文件（共4个）
拷贝以下文件到您网站的bin文件夹下
CuteEditor.dll
CuteEditor.ImageEditor.dll
NetSpell.SpellChecker.dll
CuteEditor.lic （license文件）
2.拷贝CuteEditor 客户端文件
拷贝“CuteSoft_Client”文件夹到您的网站目录下（根目录），大约有4.57MB（.NET 2.0版本）。
3.增加httpModule 到您的web.config中
（1）IIS 5.0, 6.0 和 IIS 7.0 标准模式（Classic mode）
<system.web>
<httpModules>
<add name="CuteEditor.UploadModule" type="CuteEditor.UploadModule,CuteEditor"/>
</httpModules>
</system.web>
</configuration>
（2）IIS 7.0集成模式（Integrated mode）
<system.webServer>
<modules>
<add name="CuteEditor.UploadModule" type="CuteEditor.UploadModule,CuteEditor"/>
</modules>
</system.webServer>
</configuration>
4.添加 CuteEditor 到您的页面（为了方便，先将CuteEditor.dll添加到您的VS工具栏中）
拖动工具栏中的CuteEditor控件至您的页面，CuteEditor会自动注册到您的页面。
如下：
<CE:Editor id="Editor1" runat="server" />
5.取值方法
6.效果图：