学习备忘录

http://www.javaalmanac.com - Java开发者年鉴一书的在线版本. 要想快速查到某种Java技巧的用法及示例代码, 这是一个不错的去处.
http://www.onjava.com - O'Reilly的Java网站. 每周都有新文章.
http://java.sun.com - 官方的Java开发者网站 - 每周都有新文章发表.
http://www.developer.com/java - 由Gamelan.com 维护的Java技术文章网站.
http://www.java.net - Sun公司维护的一个Java社区网站.
http://www.builder.com - Cnet的Builder.com网站 - 所有的技术文章, 以Java为主.
http://www.ibm.com/developerworks/java - IBM的Developerworks技术网站; 这是其中的Java技术主页.
http://www.javaworld.com - 最早的一个Java站点. 每周更新Java技术文章.
http://www.devx.com/java - DevX维护的一个Java技术文章网站.
http://www.fawcette.com/javapro - JavaPro在线杂志网站.
http://www.sys-con.com/java - Java Developers Journal的在线杂志网站.
http://www.javadesktop.org - 位于Java.net的一个Java桌面技术社区网站.
http://www.theserverside.com - 这是一个讨论所有Java服务器端技术的网站.
http://www.jars.com - 提供Java评论服务. 包括各种framework和应用程序.
http://www.jguru.com - 一个非常棒的采用Q&A形式的Java技术资源社区.
http://www.javaranch.com - 一个论坛，得到Java问题答案的地方，初学者的好去处。
http://www.ibiblio.org/javafaq/javafaq.html - comp.lang.java的FAQ站点 - 收集了来自comp.lang.java新闻组的问题和答案的分类目录.
http://java.sun.com/docs/books/tutorial/ - 来自SUN公司的官方Java指南 - 对于了解几乎所有的java技术特性非常有帮助.
http://www.javablogs.com - 互联网上最活跃的一个Java Blog网站.
http://java.about.com/ - 来自About.com的Java新闻和技术文章网站.
http://www.java-opensource.com/ - 介绍javaopensource的网站。

其实关于标题这个问题一向是被很多人所拿来讨论的，但其实放到国内任何一家企业都可以套用这种问题，为什么国内的小企业无法做大做强。但原理还都是一样的。当我把我转贴的这篇文章告诉我同事时，他说，很早在大富翁论坛上就已经有过讨论了。

再看看目前的软件业，软件从业人员，也能够了解一些，当我们还在努力的为工资打拼时，挣一份兼职时，却总有人跳出来破坏市场。记得在04年~05年左右，那时候在QQ群里面有人放单5000元左右，结果讨论的人不是在如何为接单议论，而是在打拼价格，最终是一名在校生以800元左右的价格接下来了。事后问那位放单的人员，才知道，后续问题一堆，接单的人做完后就消失了。仔细想来却是学校里的学生没有就业压力，接单纯粹是为了多一点生活费而考虑，而且有大把的时间，这样的情况下，计算生产成本就是不一样的了。而做出来后，却又忽略后续维护（试想接了N单之后，人人都要你维护，你有这个精力吗？只能装消失了。）这样就影响了外界对软件从业人员的误会，也认为价格和服务就这样了。唉。。

下面还是转贴文章吧，反正都可以被任何行业套用。

纵览,国内比较大的软件公司(以下统一简称"国软"),清一色都是做政府项目的(他们能做大的原因我就不用说了吧),真正能做大的国软又有几家呢? 这是为什么呢?
今天风吹就给大家简单分析下:

1."作坊"式管理
  "作坊"往往是效率最高的,国软几乎都是从作坊走过来的,
   但把作坊式的管理模式套用到一个不断壮大的公司中显然是不行的.
   组织架构到达一定程度后就必然要进行分工的细化,依靠作坊式的"暴力开发"是行不通的.

2."法制社会"
   上班必须打卡,迟到要扣钱,还一次比一次多,加班没有加班费,反正算下来就是,只有扣钱的项目,没有加钱的项目.
   比起外企,人家上班不打卡,迟到不扣钱,加班有加班费,这样宽松点的环境不好吗?

3.自身自灭
   国软一般没有师徒制,有的话也只是形式上的,公司基本没人管你,你也不用去管别人,
   新进的员工,不管会不会,先丢个东西给你做,自己研究,不懂的google去.
   这也是为什么国软喜欢招有经验的人,因为没经验的人熬不住,跑了几个以后,国软就不招了.

4.销售-开发-维护脱节
   这点是非常严重的,会直接导致项目流产的.国软的典型的做法是,销售为了业绩,在没有调研的情况下就签了合同(这里主要是指项目型的,产品型的一般可以控制),而且合同的范围也非常模糊,可大可小,接下来就是调研人员上场,调研后发现,10w块钱的合同,调研出来了100w的需求,接下来就是和客户扯皮, 最后直接导致项目流产,甚至打上官司.项目或产品上线后,维护人员对系统不了解(一方面是没有文档,另外一方面维护人员一般没有参与到开发中),接下来往往就会发生两种情况:
   a.维护人员在不了解系统的情况下擅自修改,结果导致系统越改问题越多.
   b.维护人员一不做二不休,所有客户反馈的问题全部打回给开发人员,于是开发人员就生不如死,在做别的项目的同时还要维护以前的项目,结果就是导致几个项 目都失败.

5.缺乏规划
   今天要用这个,明天想用那个(笔者就经历了公司在半年的时间内对框架进行了两次大的变动,导致开发人员都必须重新学习框架)
   产品也接,项目也接,大的也接,小的也接.

   今天领导说往左走,明天说往右走,也不能怪领导,他也没经验,我们就是他的DEMO.
   公司没有一个明确的目标,要做成什么样,只是一味的提出做大做强,但是没有规划出如何做大做强.(和我的标题一样哦)

6.三无-无需求,无设计,无测试.
   a.没有文档是国软的通病,曾几何时,产品经理丢过来的那一句话:"喂,**,给我做一个**模块来",然后开发人员就开始埋头苦写了.
   b.当然如果你天资聪慧,可以轻易理解出产品经理的意思,那有没有设计都无所谓了,但是,当有一天别人要维护你的程序的时候问题就出现了,
   没有文档,代码又那么天马行空,怎么维护?改了这个地方,又影响了那个地方...
   c.其实程序员都懂得测试的意义,可以工时安排的那么紧,哪来的时间测试?测试又没有算工时.所以几乎所有的程序员的做法就是,直接丢给用户测试
   这 时候有人肯定要问:那项目经理呢?他不是可以测试吗?请记住这是国软,刚才写代码的那个人就是项目经理,还是售前,还是设计人员,还是维护,还是...
   归结还是成本问题,在外资软件公司中,做文档的工时是比做开发的工时更多的,国软为了节省成本,这块当然要CUT掉了.不必去追去文档有多么详细多么美 观,需要做的就是找到一个平衡点,一份适合自己的文档.

7.员工都是"十项全能"
  在国软里面的员工各个都是十项全能(笔者就是一个鲜明的例子,从系统调研分析设计,到进度管理,开发,测试,验收,实施,维护,甚至拉给客户拉网线都需要 我去.)
  直接导致的结果就是这些员工每过多久就直接出来自己开公司了...嘿嘿又一家作坊诞生了...
  这样做对员工个人其实是有好处的,但是对于企业本上来说是没有好处的,并不是说员工成立了作坊,成为了你的竞争对手,而是让员工各个都是十项全能的结果就 是
  a.员工都是"十项全不能".
  b.员工一旦离职,他手头的项目必定流产.
  c.对公司的发展是不利的(细化分工).

8.莫不关心
  老板并不知道员工在做什么,员工也不知道老板在做什么.
  上级很少去关心下级的工作,更别说去关心下级的生活,一个东西丢给你,一个月后交差,中间不管你任何事情,交不了差就唯你是问.
  下级也不知道能为上级分担什么,只有等着上级分配任务.
  甚至还有些老板都不不知道员工的名字,在这样的国软的,每个人都是孤立的,又怎么能做大做强呢?

9.企业文化
  所谓十年树木,百年树人.
  国软的企业文化表面功夫算是做的很好的了,什么"为客户创造价值","做最好的行业解决方案","软件公司的最大资源就是人才"等等,要多华丽有多华丽,
  重复体现了"口号文化".真正做到企业文化又有多少呢?有多少仅仅是为了做给客户看的呢?

10.盲目跟风
  很多国软看到人家外企软件公司最近在搞什么推进活动,就跟风,效仿外企做,可是无法领悟精髓,纯粹只是在模仿.
  (外企集体笑:"一直被模仿,从未被超越")
  做完了也不知道这么做的意义,劳民伤财.

11.缺乏"执行力"
  国软的通病,就是"执行力",国软的学习劲头很足,今天提出要完善测试标准,明天提出要每周写工作报告,可是又有哪些东西能真正的去执行呢?
  导致这个问题的主要原因有两个:

  a.提出来的东西到底有没必要做,还是只是应付领导走个过场.
  b.谁来跟踪这些东西?员工写了工作报告,领导没有去查看,去反馈, 员工觉得写的也没意义,自然不会继续执行下去.

12.管理混乱
    没有划分清楚员工的归属组织,员工并不明确他的上级领导是谁,导致有的员工处于游离状态,有的是员工又是多个领导,不懂要听谁的,有些人忙的要死,有些人 又闲的要命,最后搞的最痛苦的就是员工,导致员工离职.

13.缺乏团队精神
   为什么会缺乏团队精神呢?并不是国软没有这方面的概念,国软也很希望培养员工的团队观念和精神,
   无奈因为国软,一般都是一个人负责一个或者多个项目,连团队都没有,何来的团队精神?

14.无法做到补足
   一个项目一旦中途有人辞职,这个项目就会流产.
   一个员工一旦辞职,会有N个项目没人维护.
   A组的员工无法胜任B组的工作,归根结底就是组织上根本没有考虑过组织变动对项目的影响,没有提前培养人员.

15.一成不变和随心所欲
   有两类人一种是把前辈的东西COPY过来,不作任何修改,因为他深信,前辈的一定是对的,
   还有一类是不管前人怎么做的,一律不要,全凭自己的"经验",随心所欲,天马行空的进行自主研发,

   造成的结果就是错的还是错的,乱的更乱了.

16.人才育成
   成本,还是成本,培养一个人要多少成本?
   这就是国软做不大的原因,永远只能停留在"作坊"的原因.

17.向心力.
     老板做的是事业,员工做的是事情,这是国软员工的一致观点.

18.恶性循环
     a.人员力量不足 -> 接不了项目 -> 收入少 -> 人员流失.
     b.人员力量不足 -> 强行接项目 -> 亏本    -> 破产.

最后我想说一句的是:成也国软,败也国软.说的不对的地方请大家指出,或者补充下没说到的地方.

--EOF--

原文来自：http://www.cnblogs.com/saul/archive/2010/04/20/1715793.html

第1章 テストという仕事

鉄則001 プロジェクトの行く手を照らせ
鉄則002 常に目的を意識せよ
鉄則003 テストは幅広い顧客へのサービス業だと心得よ
鉄則004 顧客の価値と向き合うこと
鉄則005 重大なバグを素早く見つけよう
鉄則006 プログラマとは二人三脚で進め
鉄則007 口に出さなくても，いろいろ疑問を持とう
鉄則008 プログラムの失敗を成功の母とせよ
鉄則009 バグを全部見つけるのは無理だと心得よ
鉄則010 テスト「完了」と聞いたら注意すべし
鉄則011 テストで品質が保証できるなどと思うな
鉄則012 門番になるな
鉄則013 「私の仕事じゃありません」と言ってはならない
鉄則014 プロセス改善グループには気軽に変身するな
鉄則015 みんながテストを知っているわけじゃない

第2章 実践的テスト担当者の思考法

鉄則016 認識論を駆使すること
鉄則017 認識論の手法を使ってテストを鋭くする
鉄則018 認知心理学も駆使する
鉄則019 テストは思考の産物だ
鉄則020 テストには推理力が必要となる
鉄則021 技術的，創造的，批判的，実践的な思考が優れたテストのカギ
鉄則022 ブラックボックステストは「何も考えていないテスト」ではない
鉄則023 漫然と操作することはテストとは呼ばない
鉄則024 テストは質問の答えを探す作業である
鉄則025 モデリングはテストの決め手だ
鉄則026 直感は糸口として有用だが，判断の根拠に使ってはならない
鉄則027 テストとは探求することだ
鉄則028 探求のためには三つの思考法がある
鉄則029 仮説的推論の技法を使え
鉄則030 推論と反証の方法論で製品を評価せよ
鉄則031 本当の「要求仕様」は何かを把握せよ
鉄則032 要求仕様書をあてにするな
鉄則033 明文化されていない仕様もあることに気を付けよ
鉄則034 「動いた」の本当の意味を確認せよ
鉄則035 結局，テスト結果は製品に対する「印象」に過ぎない
鉄則036 「テスト」と「テストをする」ことを混同してはならない
鉄則037 複雑なテストは速攻の繰り返しでこなせ
鉄則038 テストのアイデアがすぐ欲しいとき，経験則が役に立つ
鉄則039 思い込みから逃れられなくても，上手く付き合うことはできる
鉄則040 騙されやすいと自覚することが騙されない秘訣
鉄則041 たまたまか，当然の結果か，そこを見分けよ
鉄則042 混乱をテストに生かすべし
鉄則043 慣れは見落としの素，新鮮な眼をいつも絶やさずに
鉄則044 手順に従うのではなく，手順を従わせる
鉄則045 「1287 文字入力せよ」などと書いてはいけない
鉄則046 テスト技術者の成長もテストの成果の一つである
鉄則047 習うだけではテストの達人にはなれない

第3章 テストの技法

鉄則048 テストの五大要素をいつも念頭に置け
鉄則049 人に着目したテスト技法は，誰がテストするのかがポイント
鉄則050 網羅性（カバレッジ）に着目した手法は，どこまでテストするかがポイント
鉄則051 問題に焦点をあてた技法は，どんなリスクがあるかがポイント
鉄則052 作業に焦点をあてた技法は，どうテストするかがポイント
鉄則053 合否判定に焦点をあてた技法は，合否の判断基準がポイント
鉄則054 テスト技法の分類は，各人の捉え方によって変わる

章末付録
　入力フィールド用のテストマトリクスを作成する方法
　繰り返し発生する問題用のテスト一覧の作成方法
　仕様に基づくテストに利用するトレーサビリティマトリクスの作成方法
　全ペア技法を用いた組み合わせテストの実施方法
　プログラムの構成要素やさまざまな側面に関連するリスクの分析方法
訳者補足
　直交表を用いた全ペアのテストケースの作成例

第4章 バグの報告

鉄則055 報告の内容でテストをした“人”がわかる
鉄則056 正しく伝えてこそ修正がなされる
鉄則057 障害レポートを商売道具として活かせ
鉄則058 障害レポートはテスト実施者の名刺である
鉄則059 障害レポートの価値を高めるための，手間暇を惜しむな
鉄則060 誰でもバグを報告できることが大切
鉄則061 他人の障害レポートの書き換えは安易にやるな
鉄則062 期待に合わない品質もバグとして扱え
鉄則063 テストを担当したら，バグ報告できない人たちの代弁者となれ
鉄則064 修正に難色を示されそうなバグは，関係者の注意を引くように障害レポートを書け
鉄則065 障害管理システムをプログラマの評価に使うな
鉄則066 障害管理システムをテスト実施者の評価にも使うな
鉄則067 バグの報告は新鮮さが大切
鉄則068 目立つから報告されているという思い込みは危険
鉄則069 設計の不具合を検出するのもテストの目的
鉄則070 極端な条件でのバグはセキュリティ上の潜在的なリスク
鉄則071 重箱の隅をつつけ
鉄則072 修正に値しないバグはない
鉄則073 優先度と重要度を区別せよ
鉄則074 バグの外見に惑わされるな
鉄則075 些細なコーディングエラーを見つけたならテストを追加せよ
鉄則076 再現しないエラーも全て報告せよ。時限爆弾になる恐れがある
鉄則077 再現できないバグはない
鉄則078 障害レポートの処理コストにも注意を払え
鉄則079 ツールや環境関連バグへの感度を上げよ
鉄則080 バグ報告の前に，プロトタイプや非公式プログラムでないかを確認せよ
鉄則081 重複した障害レポートは問題解決促進剤になる
鉄則082 障害レポートは1 件1 葉
鉄則083 障害レポートはタイトルで決まる
鉄則084 バグをありのままに報告せよ
鉄則085 問題点をはっきり報告し，解決策は書かない
鉄則086 誰が読むか分からない。言葉使いには十分注意すること
鉄則087 疲労困ぱいで不機嫌な人に読まれると思え。報告書は極力読みやすく
鉄則088 報告のスキルアップに努めよ
鉄則089 必要なときは，マーケットデータやサポートデータを活用せよ
鉄則090 障害レポートをクロスレビューせよ
鉄則091 相手に直接会っておこう
鉄則092 ときには障害を実演してみせる
鉄則093 「直した」と言われたら，別の所に問題が出てきていないか確認せよ
鉄則094 バグ確認は鮮度が命
鉄則095 修正が失敗していたらプログラマと直接話し合おう
鉄則096 障害レポートに終止符を打つのはテスト担当者の役割
鉄則097 すべてのバグ修正を強制するな。戦いの場は選ぶべきだ
鉄則098 保留したバグを消失させるな
鉄則099 バグ修正をテストがうまくできない理由にするな
鉄則100 バグ保留判定への抗議は即座に行え
鉄則101 戦うときは，必勝の決意で戦え

第5章 テストの自動化

鉄則102 目的はコストダウンではない，開発プロセスの迅速化だ
鉄則103 同じことの繰り返しではなく，手法を変えて深堀りせよ
鉄則104 状況に応じて自動化の戦略を選択せよ
鉄則105 自動化は“銀の弾丸”にはならない
鉄則106 テストツールに使われるな
鉄則107 ゴミクズを自動化しても意味はない
鉄則108 手動テストと自動テストを同格に扱うな
鉄則109 同じテストを何度も繰り返せるだけではモトは取れない
鉄則110 回帰テストを自動化しただけではバグは出ない
鉄則111 自動化で埋もれてしまうバグもある
鉄則112 自動テストの失敗のツケは忘れた頃にやってくる
鉄則113 テスト記録の再生は思うようには機能してくれない
鉄則114 テストツールにもバグはつきもの
鉄則115 ユーザインタフェースは変わるためにある
鉄則116 GUI テストツールは，互換性と習得性とサポートで選べ
鉄則117 自動化した回帰テストはすぐに陳腐化していく
鉄則118 テストの自動化はソフトウェア開発そのものである
鉄則119 テストの自動化は決して安くない投資である
鉄則120 テストの自動化に必要なのは，プログラミング，テスト，プロジェクト管理のスキル
鉄則121 自動化の検証にはパイロットプロジェクトを利用せよ
鉄則122 テストの自動化はテスト側と開発側との協調が必要である
鉄則123 自動化テスト環境の開発にはレビューを活用せよ
鉄則124 自動化テスト設計に手抜きは厳禁
鉄則125 テストスクリプトは簡潔をモットーとせよ
鉄則126 反復コードを避けるためだけにテストライブラリを構築するな
鉄則127 テスト変数の多さに閉口したときは，データ駆動型自動テストを使え
鉄則128 プログラマ以外ならキーワード駆動型自動テストが最適
鉄則129 入力データを自動生成するにはコツがある
鉄則130 テストツールはデータと処理とを分離せよ
鉄則131 汎用的スクリプト言語を使え
鉄則132 自動化のためにはプログラミングインタフェースを活用しろ
鉄則133 単体テスト環境をぜひ作れ
鉄則134 テストを理解していないプログラマには要注意
鉄則135 テストを軽んじる者にはテストツールは作れない
鉄則136 自動化よりテスト容易性を上げることにまず投資せよ
鉄則137 「テスト容易性」とは可視性と操作性である
鉄則138 テストの自動化計画はプロジェクトの早い段階に立てる
鉄則139 自動化専門チームはできることを明確に文書で示せ
鉄則140 即効性のある自動化から始めよ
鉄則141 まず自らの道具箱を見直せ

第6章 テストドキュメント

鉄則142 問題を見据えた上で対策を打て
鉄則143 テンプレートはそれが必要ない上級者にしか使いこなせない
鉄則144 コミュニケーションを首尾一貫させるにはテンプレートも役立つ
鉄則145 IEEE 829 標準規格も使い方次第
鉄則146 IEEE 829 標準規格の問題点を理解せよ
鉄則147 はじめに要件分析ありき，たとえテストでも
鉄則148 テストドキュメントの要件分析に役立つチェックリストを覚えておこう
鉄則149 テストドキュメントの核となる要件を最大三つに集約した要約文を作ってみよう

第7章 プログラマとの協同作業

鉄則150 プログラマの考え方を理解せよ
鉄則151 プログラマから信頼を勝ち得よ
鉄則152 プログラマとは共存共栄であれ
鉄則153 自らの誠実さと能力を示さずに技術的信頼関係など築けない
鉄則154 バグを憎んで人を憎まず
鉄則155 プログラマとは人にモノを教えるのが好きな人種である
鉄則156 テストの容易さはプログラマの責任

第8章 テストプロジェクトのマネジメント

鉄則157 「サービス」文化を創り上げよ
鉄則158 「管理」文化にするな
鉄則159 情報発信の網を張りめぐらせろ
鉄則160 対象をテストプロジェクトに絞り込め
鉄則161 プロジェクトを正しい方向に進化させよ
鉄則162 要求は常に変更されるものだと心得よ
鉄則163 機能，信頼性，時間，コストの間のトレードオフ関係に注意しろ
鉄則164 ライフサイクルをプロジェクトマネージャに選択させよ
鉄則165 ウォータフォールモデルでは信頼性と時間が対立する
鉄則166 エボリューショナリライフサイクルでは機能と時間が対立する
鉄則167 開発初期段階にリソースを積極的に投入せよ
鉄則168 カスタムソフトとパッケージソフトの開発は違う
鉄則169 テスト容易性のための機能を要請せよ
鉄則170 ビルドスケジュールを調整せよ
鉄則171 ビルド引き渡し前のプログラマの仕事を把握せよ
鉄則172 ビルドの受け入れ準備は怠るな
鉄則173 ときにはビルドのテスト受け入れを拒否することも大切だ
鉄則174 まずはスモークテストで判断せよ
鉄則175 テストを中止しソフトウェアを書き直した方がよいこともある
鉄則176 郷に入れば郷に従え
鉄則177 プロジェクトドキュメントは絵空事であることを念頭に置け
鉄則178 使わないなら詳細仕様を求めるな
鉄則179 情報の引き出しは多く持て
鉄則180 プロジェクトマネージャに構成管理の問題を気付かせろ
鉄則181 プログラマはまるで竜巻のようなもの
鉄則182 後工程の変更を容易に取り込めてこそ良いテスト計画である
鉄則183 レビュー準備と同時にテスト準備も行え
鉄則184 どのくらいテストをすればよいかという質問に解はない
鉄則185 「充分なテスト」とは「正しい状況判断を下すのに充分な情報を得られること」である
鉄則186 テストサイクルが２ 回程度で終わると思うな
鉄則187 個々のタスク工数を積み上げて，全体スケジュールを見積もる
鉄則188 作業時間は担当者に見積もらせるべきである
鉄則189 テストの担当者と開発者の人員の比率に正解はない
鉄則190 適材適所を心がけよ
鉄則191 担当機能をローテーションさせよ
鉄則192 ペアテストを試みよ
鉄則193 バグ探しの達人をプロジェクトに入れろ
鉄則194 テスト前に，テスト方針を示せ
鉄則195 テストの集中時間を設けよ
鉄則196 テスト作業を邪魔する割り込みを把握するため作業記録をつけよ
鉄則197 定期的な進捗報告は強力なテストツールだ
鉄則198 数字しか見ない経営陣ほど危険なものはない
鉄則199 バグ総数によるプロジェクト進捗測定はするな
鉄則200 カバレッジも使い方による
鉄則201 進捗報告にバランススコアカードを適用せよ
鉄則202 週報はこう書け
鉄則203 プロジェクトダッシュボードで進捗状況を分かりやすく示せ
鉄則204 適切に設定してこそマイルストーン毎での状況報告は有効となる
鉄則205 リリースの最終判断はプロジェクトマネージャにさせる
鉄則206 製品リリースの際にはコメントを付け加える
鉄則207 リリースレポートには意見でなくテスト結果を記載せよ
鉄則208 最終リリースレポートには未修正のバグリストを付けよ
鉄則209 批評家が批判に使う10 の悪い事柄をリストアップしたリリースレポートを書いてみよ

第9章 テストグループのマネジメント

鉄則210 没個性の行き着くところは無気力充満の職場である
鉄則211 部下を一人の経営者として扱え
鉄則212 部下の障害レポートに目を通せ
鉄則213 部下を一人の経営者として評価せよ
鉄則214 状況を知りたければ一緒にテストしろ
鉄則215 「かけもち」はできそうでできない
鉄則216 専門家としての知見を身に付けられれば，「できる」部下が育つ
鉄則217 テストのプロは，関連技術の知見も磨け
鉄則218 バリバリ働き，スキルを磨け
鉄則219 技術サポートのログを見直せ
鉄則220 新人のスタートを後押しせよ
鉄則221 新人はまずドキュメントのチェックから
鉄則222 基本操作のテストで製品に慣れさせる
鉄則223 障害レポートは新規より過去のレポートの書き直しから
鉄則224 新規バグより過去のバグの再テストから
鉄則225 プロジェクトの終盤に初心者を投入するな
鉄則226 スタッフの士気こそ貴重な財産
鉄則227 自分をいじめるな
鉄則228 部下を残業で苦しめるな
鉄則229 部下を虐待から守れ
鉄則230 教育の機会を与えよ
鉄則231 採用の決断が一番重要
鉄則232 外注でとりあえず息をつなぐ
鉄則233 はみ出し者はめったに受け入れるな
鉄則234 必要なスキルを持つ者を必要なポジションに
鉄則235 テストチームには多種多様な人員構成を
鉄則236 雇えば使えるこんな人々
鉄則237 メンバに受け入れられる人を採用しよう
鉄則238 仕事を大切にする人を採用しよう
鉄則239 誠実な人を採用しよう
鉄則240 採用面接では実技試験を行え
鉄則241 パズルでテストへの適性は計れない
鉄則242 採用時には過去の実績を確認せよ
鉄則243 採用を決めたら迅速に処理せよ
鉄則244 無責任な口約束は厳禁

第10章 ソフトウェアテストにおけるキャリア

鉄則245 将来の姿を見据えてキャリアを積め
鉄則246 プログラマより高収入を狙え
鉄則247 枠にとらわれずキャリアを追求せよ
鉄則248 キャリアは自らで築け
鉄則249 テスト以外のキャリアへ進め
鉄則250 会社以外の場所でキャリアを伸ばせ
鉄則251 外部会議は人脈の宝庫
鉄則252 他社も苦労している
鉄則253 今の会社がイヤなら他を探せ
鉄則254 自らの地位を賭す状況に備えよ
鉄則255 働きたい企業をリストアップせよ
鉄則256 自身のポートフォリオを準備せよ
鉄則257 履歴書を販売用ツールとして使いこなせ
鉄則258 コネを活かせ
鉄則259 給料の水準を知れ
鉄則260 求人広告に自分を合わせろ
鉄則261 面接は場数も大事
鉄則262 ここぞと思う企業はとことん調べよ
鉄則263 面接では臆するな
鉄則264 ポジションを獲得するための交渉術に長けよ
鉄則265 採用権は誰にあるかを考慮せよ
鉄則266 Perl を学べ
鉄則267 Java かC++を学べ
鉄則268 世の中のテストツールを知っておくこと
鉄則269 文章力を磨け
鉄則270 プレゼン能力を磨け
鉄則271 資格取得について考えよ
鉄則272 ２ 週間でとれた黒帯など実戦では使えない
鉄則273 ソフトウェア技術者ライセンスを取得することに価値があるかを見極めよ

第11章 テスト戦略の立案

鉄則274 三つの質問を携えてテスト戦略を立案せよ
鉄則275 一つの選択肢にとらわれてテスト戦略を立案するな
鉄則276 テストの進め方の指針をまとめたものがテスト計画である
鉄則277 テスト計画は状況に合わせるべし
鉄則278 テスト計画は戦略，段取り，成果物の三位一体と心得よ
鉄則279 目先の作業に追われて戦略を見失うな
鉄則280 テストケースの項目数からは何も分からない
鉄則281 テスト戦略はテスト項目より重要だと心得よ
鉄則282 テストの質は戦略に左右されると肝に銘じろ58
鉄則283 多様的ほどほどの原則でテストする
鉄則284 テスト戦略を実践するためにリソースを揃えるべし
鉄則285 最初の戦略はいつも間違っていると思え
鉄則286 「どうすればより良いテストができるか」を常に問い続けよ
鉄則287 製品の成熟度に応じてテストせよ
鉄則288 テストをレベルに分けて作戦をたてろ
鉄則289 グレーボックステストを実施せよ
鉄則290 古いテストの再利用には注意しろ
鉄則291 人が変われば見方も変わると心得よ
鉄則292 プロジェクトのリスクもテスト戦略に組み込め
鉄則293 テストサイクルをテスト作業の鼓動とみなせ

章末付録１ コンテキスト駆動型テスト計画
　1.テスト計画上の主要な課題を監視する
　2.目的を明確にする
　3.製品を分析する
　4.リスクを分析する
　5.テスト戦略を立てる
　6.段取りを決める
　7.テスト計画を共有する

章末付録２ 「良いテスト計画」の構成要素
　用語と概念
　テスト計画の役割
　テスト計画の品質基準
　テスト計画の経験則

付録 ソフトウェアテストに対するコンテキスト駆動型アプローチ

参考文献
訳者あとがき
索引

機能テストの話
機能テストって何かしら
•ブラックボックステスト
•アプリケーションを実際に操作してテストする
•受け入れテストとも言う
テストの種類
•RAT
•FAST
•TOFT
•FET
•境界条件テスト
•探索型テスト
RAT (Release Acceptance Test) リリース時受け入れテスト
スモークテストとも言う。

アプリケーションがとりあえず動作、機能テスト可能な状態にあるかどうかを確認するテスト。
なので実は機能テストではない。

アプリケーションを起動できるか、文法エラーで動かないところはないか、動作に必要なリソース（データベース等）に接続できているか、といったレベル。

FAST (Functional Acceptance Simple Test) 受け入れ時簡易機能テスト
広く浅い範囲を対象とした最低限の機能テスト。
軽量なので一回のテストにかかるコストが少なく、素早く実行できる。

対象は以下のとおり。

•リンク
•UIコントロール（入力、ナビゲーション）の挙動
•追加、削除、更新などのデータ変更テスト
•ログイン、ログアウトなどのその他主要機能
すでにテスト環境で完全なテストを通っているものを他の環境（本番環境や開発環境など）へリリースした際に行ったりする種類のテスト。

TOFT (Task-Oriented Functional Test) タスク指向機能テスト
プログラムの機能を確認するいわゆる正常系のテスト。

ユーザがタスクを完了できるかどうか、実行される各タスクの完全性を確認する

•様々なデータの入力に対してデータ出力が常に適切であるかどうかをチェック
•他の関連する機能と組み合わせた場合の完全性
網羅性が要求される。

FET (Force-Error Test) 強制エラーテスト
いわゆる異常系のテスト。

エラーを意図的に発生させ、エラー処理が正しく機能しているかどうかをテストする。
エラーによってアプリケーションが不安定になったり、データが破損することがないことを確認する。

•エラーを意図的に発生させる
•エラー検出の確認
•エラー処理の確認（エラーから復帰できるか、データ等に異常は発生してないか）
•エラー通知の確認（エラーメッセージが表示されたか、内容は適切か）
•エラーによるそのほかの障害が発生していないか探す（エラー処理に抜けがないか等）
境界条件テスト
TOFTやFETの延長線上にあるテスト。
テストに用いる各変数の境界値をテストする。

等価クラスから境界値を分析してテスト変数を絞る。

テスト変数を絞ることはリスクだが、リソース節約のメリットの方がはるかに大きい。

等価クラス
どの値を入力しても結果が同じように処理される。それらの値は等価クラスとしてひとまとめにできる。

•数の範囲（2桁の数字 10-99 など）
•グループ（日付、時刻、国名など）
•不正な入力（半角数字のみ許可のところに半角英字、記号、全角文字など）
•等価な動作環境（同じバージョンのOSの別々のマシン）
境界値
等価クラスから別の等価クラスへ移行する境界
境界値付近ではエラーが起こりやすいので、

•許容される入力値と許容されない入力値の境界
•サポートされるシステム要件とサポートされないシステム要件の境界
ひとつの境界値からは多くとも最大9のテストケースが得られる。

•有効値の範囲
•有効値の最小
•有効値の最小+1
•有効値の最小-1
•有効値の最小-α（確実に有効値より小さい）
•有効値の最大
•有効値の最大+1
•有効値の最大-1
•有効値の最大+α（確実に有効値より大きい）
他に文字列の等価クラスや小数点や前ゼロのついた数字のような特別なクラスなどが存在する。
ひとつのフィールドの値に関して等価クラスがたくさんあれば境界値もそれだけ増える。

境界値を使ったテストケースの作成
•等価クラスを見つける
•境界を見つける
•有効な入力に対する出力結果を予想する
•不正な入力に対するエラー処理を予想する
•テストケース一覧の作成
探索型テスト
アプリケーションを操作して未知のバグを見つけ出すためのテスト。
学習、計画、実行を同時に行う。

どのテストを使うか
•継続的インテグレーションにともなう完全なテスト -> TOFT, FET, 境界条件テスト
•テスト済みアプリケーションのリリース時 -> FAST
•リリース前の積極的なデバッグ作業 -> 探索型
機能テストの自動化
なんでもかんでも自動化すればいいってもんでもない。

•自動化にはしっかりとした計画が必要
•自動化の前にテスト容易性を強化したほうがよい
•ダメな自動化は無駄
•自動テストが複雑すぎるとテスト自体にバグが
•でもやっぱ好き
•複数人で作る場合は命名規約などのガイドラインがあったほうがよい
作成コストと保守コスト
•アプリケーションの規模が大きくなるほど作成コストがかさむ
•アプリケーション更新のプロセスに組み込まないとすぐに陳腐化する
•つまり保守コストもかかる
•保守コストがアプリケーションの開発速度に影響する
•UI変更で全滅したりする
保守性の高いテスト
•ちょっとした文言変更くらいには影響されない
•他のテストの変更に影響されない
機能テストを減らす工夫
•ユニットテストにまかせる
•モデルのバリデーションテストなど
•フレームワークを利用する
•フレームワークが面倒見てくれる部分のテストは割愛
•テストを書きやすいフレームワークもある Railsとか
テストライブラリ構築上の注意
•複雑すぎる処理はそれ自体にバグが埋まる可能性
•整理しておかないと同じようなものがいくつも作られて混乱の元に
テスト容易性
可視性
•ソースコード
•ログ出力
•デバッグ出力
エラーの原因がすぐに追跡できること。わかること。

操作性
•エラーシミュレーション
•診断コマンド
•テスト用API
エラーの状態を再現しやすいこと。

自動テストの対象としてGUIがいいかテスト用APIがいいかは意見が分かれる。
SeleniumはGUI

参考文献
•『インターネットアプリケーションのためのソフトウェアテスト』
•『ソフトウェアテスト293の鉄則』

db.set_character_set('utf8')
dbc.execute('SET NAMES utf8;')
dbc.execute('SET CHARACTER SET utf8;')
dbc.execute('SET character_set_connection=utf8;')

"db" is the result of MySQLdb.connect
"dbc" is the result of db.cursor()

keepalived+drbd+daemonotoolsを使ってhadoopのHA方案
システム構成
サーバ二台
ネットワーク通信用インタフェース：eth1
それぞれ、node1とnode2を呼ばれる
使うもの：
keepalivedのviip機能で仮想IPを自動的に切り替え
drbdで二台サーバの間にディスクを同期化する
daemontoolsでhadoopのマスタサーバのプロセスとkeepalivedとdrbdサービスの状態を監視し、落ちだら、立ち直してくれる
一、keepalivedの設置
１、必要なものをチェックとインストール
openssl openssl-devel poptパッケージが必要なので、チェックした結果を見て、存在しないなら、インストールする
[root@super03 ~]#yum install openssl openssl-devel popt
２、keepalivedのインストール（ソースから）
[root@super03 ~]# cd /usr/local/src
[root@super03 src]#wget http://www.keepalived.org/software/keepalived-1.1.15.tar.gz
[root@super03 src]#tar zxvf keepalived-1.1.15.tar.gz
[root@super03 src]#cd keepalived-1.1.15
[root@super03 keepalived-1.1.15]# ./configure
[root@super03 keepalived-1.1.15]# make
[root@super03 keepalived-1.1.15]# make install
３、設定
下記のように設定する
[root@super03 keepalived]# vi /usr/local/etc/keepalived/keepalived.conf
global_defs部分がそのままでもいい
vrrp_instance VI_1 {
state BACKUP
interface eth1 # インタフェース
garp_master_delay 5
virtual_router_id 51
priority 100
nopreempt
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.0.10.200 #仮想IPアドレス
}
notify_master "/usr/local/sbin/keepalived-master" #マスタ状態になった後に実行させたいシェルスクリプト
notify_backup "/usr/local/sbin/keepalived-backup" #バックアップ状態になった後に実行させたいシェルスクリプト
notify_fault "/usr/local/sbin/keepalived-backup" #インタフェースをダウンした後に実行させたいシェルスクリプト
}
後ろ部分要らなくて、全部削除しよう
[root@super03 ~]# vi /usr/local/etc/rc.d/init.d/keepalived
stop() {
echo -n $"Stopping $prog: "
killproc keepalived
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog
/usr/local/sbin/keepalived-backup #サービスをダウンにしたときにバックアップになるよう
}
４、サービス登録と起動
[root@super03 etc]# ln -s /usr/local/etc/rc.d/init.d/keepalived /etc/init.d/keepalived
[root@super03 etc]# ln -s /usr/local/etc/sysconfig/keepalived /etc/sysconfig/keepalived
[root@super03 ~]# mkdir /etc/keepalived
[root@super03 ~]# ln -s /usr/local/etc/keepalived/keepalived.conf /etc/keepalived/
[root@super03 ~]# ln -s /usr/local/sbin/keepalived /usr/sbin/
[root@super04 etc]# chkconfig --add keepalived
[root@super04 etc]# chkconfig keepalived on
[root@super04 etc]# service keepalived start
備考：
node1とnode2同じように設定する
確認方法：ip addr show eth1
二、DRBDの設置
１、インストール（ソースから）
[root@super03 ~]# yum install flex #flexが必要なので
[root@super03 ~]# cd /usr/local/src
[root@super03 src]#wget http://oss.linbit.com/drbd/8.2/drbd-8.2.6.tar.gz
[root@super03 src]#cd drbd-8.2.6
[root@super03 src]#make all install
２、同期化用のパーティションの作成
fdiskでディスクからパーティションを作る
[root@super03 etc]# fdisk /dev/xvdb #後ろは、ディスク設備名である
３、コンフィグ設定
[root@super03 etc]# vi /etc/drbd.conf
425行をコメントアウトする
# after "r2";
resource "r0" セクション
on amd子セクションが下記の用に設定する
on super03 { #マシンの名前（node1）
device /dev/drbd0;
disk //dev/mapper/VolGroup00-LogVol03; # ステップ2で作ったパーティション
address 10.0.10.123:7788; #ディスク同期化用のIPとポート(node1)
flexible-meta-disk internal;
}
on super04 { #マシンの名前（node2）
device /dev/drbd0;
disk /dev/mapper/VolGroup00-LogVol03; # ステップ2で作ったパーティション
address 10.0.10.124:7788; #ディスク同期化用のIPとポート(node2)
meta-disk internal;
}
467行から全部削除する
此処まで、node1とnode2同じように設置しておく
４、初期化と起動
a.node1の動作
[root@super03 etc]# drbdadm create-md r0 #メータ情報の初期化
[root@super03 etc]# /etc/init.d/drbd start #DRBDを起動する
略
(These values are for resource 'r0'; 0 sec -> wait forever)
To abort waiting enter 'yes' [ 17]:yes
略
[root@super03 etc]# drbdadm -- -o primary all #プライマリ状態にする
[root@super03 etc]# mkfs /dev/drbd0 #ファイルシステムを作る
[root@super03 etc]# mkdir /mnt/drbd0 #マウント先ディレクトリを作る
[root@super03 etc]# mount /dev/drbd0 /mnt/drbd0 #マウントする
[root@super03 ~]# chkconfig --add drbd #サービスに登録
[root@super03 ~]# chkconfig drbd on #OS起動するときに自動的に起動するように
b.node2の動作
[root@super03 etc]# mkdir /mnt/drbd0 #マウント先ディレクトリを作る
[root@super04 etc]# /etc/init.d/drbd start #DRBDを起動する
[root@super04 ~]# chkconfig --add drbd #サービスに登録
[root@super04 ~]# chkconfig drbd on #OS起動するときに自動的に起動するように
５、手動で切り替え方法
activeサーバで/usr/local/sbin/keepalived-backupを実行させる
他のサーバで/usr/local/sbin/keepalived-masterを実行させる
６、備考
a.backupサーバがstandalone状態になった場合の解決方法:
そのサーバ上で下記のコマンドを実行させること
drbdadm -- --discard-my-data connect resource
b.両方もstandalone状態に成った場合の解決方法：
node1:drbdadm disconnect resource
node2:drbdadm disconnect resource
activeサーバ:drbdadm connect resource
他のサーバ:drbdadm -- --discard-my-data connect resource
三、hadoopとの組み合わせる
１、hadoopのメータ情報保存先を/mnt/drbd0移行
drbdがactiveサーバに下記のコマンドを実行する
[root@super03 drbd-8.2.6]# mkdir /mnt/drbd0/hadoop
[root@super03 drbd-8.2.6]# chown hadoop:users /mnt/drbd0/hadoop
[root@super03 drbd-8.2.6]# su - hadoop
[hadoop@super03 ~]$ mkdir /mnt/drbd0/hadoop/dfs
[hadoop@super03 ~]$ rsync -ac 元保存先 /mnt/drbd0/hadoop/dfs
２、設定
[hadoop@super03 ~]$vi $HADOOP_CONF_DIR/hadoop-site.xml

dfs.name.dir
/mnt/drbd0/hadoop/dfs/v19-name
namenodeのメータ情報の保存先


fs.checkpoint.dir
/mnt/drbd0/hadoop/dfs/namesecondary
secondarynamenodeの一時メータ情報の保存先


fs.default.name
hdfs://192.168.200.50:9000
仮想IPをnamenodeのIPとする


mapred.job.tracker
192.168.200.50:9001
仮想IPをjobtrackerのIPとする

３、シェルスクリプトを作る
[hadoop@super03 ~]$vi /home/hadoop/bin/stop-hadoop-master.sh # hadoopユーザとして登録
#!/usr/bin/env bash
# Stop hadoop namenode and jobtracker daemons. Run this on master node.
hadoop-config.sh
hadoop-daemon.sh --config $HADOOP_CONF_DIR stop namenode
hadoop-daemons.sh --config $HADOOP_CONF_DIR --hosts masters stop secondarynamenode
hadoop-daemon.sh --config $HADOOP_CONF_DIR stop jobtracker
[hadoop@super03 ~]$ chmod +x /home/hadoop/bin/stop-hadoop-master.sh # 該当スクリプトを実行できるように設定する
[hadoop@super03 ~]vi $HADOOP_CONF_DIR/masters
localhost #ローカルにする、止められるように
[root@super04 ~]# vi /usr/local/sbin/keepalived-backup
#!/bin/sh
if [ -d /mnt/drbd0/hadoop ]; then
su - hadoop -c "stop-hadoop-master.sh" | logger
sleep 1
umount /mnt/drbd0
drbdadm secondary all
else
drbd_status=`service drbd status|grep StandAlone | gawk '{print $2}'`
if [ -n "$drbd_status" ]; then
drbdadm -- --discard-my-data connect r0
fi
fi
[root@super04 ~]# vi /usr/local/sbin/keepalived-master
#!/bin/sh
# the follow is result sample of the service drbd's status when inconsistent
#service drbd status
#drbd driver loaded OK; device status:
#version: 8.2.6 (api:88/proto:86-88)
#GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by root@super04, 2009-02-18 11:53:45
#m:res cs st ds p mounted fstype
#... sync'ed:100.0% (108/664)K
#0:r0 SyncTarget Secondary/Primary Inconsistent/UpToDate C
while :
do
drbd_status=`service drbd status|grep Inconsistent | gawk '{print $4}'`
if [ -n "$drbd_status" ]; then
echo "drbd's status is inconsisten,waiting..."
sleep 1
else
echo "drbd's status is ok,namenode will be changing"
break;
fi
done
while :
do
if [ -d /mnt/drbd0/hadoop ]; then
su - hadoop -c "stop-mapred.sh;start-all.sh" | logger
break
else
drbdadm primary all
mount /dev/drbd0 /mnt/drbd0
sleep 1
fi
done
四、daemontoolsの導入
1．/package ディレクトリを作成
# mkdir -p /package
# chmod 1755 /package
# cd /package
2.daemontools-0.76.tar.gzをダウンロード
# wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
# tar zxvf daemontools-0.76.tar.gz
# cd admin/daemontools-0.76
3.インストール
# package/install
......
/usr/bin/ld: errno: TLS definition in /lib/libc.so.6 section .tbss mismatches non-TLS reference in envdir.o
/lib/libc.so.6: could not read symbols: Bad value
collect2: ld はステータス 1 で終了しました
make: *** [envdir] エラー 1
Copying commands into ./command...
cp: cannot stat `compile/svscan': そのようなファイルやディレクトリはありません
4．対処方法
# cd /package/admin/daemontools-0.76
# wget http://qmail.org/moni.csi.hu/pub/glib ... montools-0.76.errno.patch
# patch -s -p1 <./daemontools-0.76.errno.patch
# package/install
略
Copying commands into ./command...
Creating symlink daemontools -> daemontools-0.76...
Making command links in /command...
Making compatibility links in /usr/local/bin...
Creating /service...
Adding svscanboot to inittab...
init should start svscan now.
成功に終わりだ
以上の作業で、以下のディレクトリとファイルが作成されます。
* 新たに作成されるディレクトリ
/service
/command
* 作成されるファイルおよびそのシンボリックリンク
/package/admin/daemontools/command/下に実行ファイル
/command/下にそのシンボリックリンク
/usr/local/bin/下にさらにシンボリックリンク
　また、/etc/inittabファイルの末尾に次の1行が追加されます。
SV:123456:respawn:/command/svscanboot
５、サービスを追加
プロセス監視サービスを追加
概要仕様：
監視サービス中で、起動させる、service サービス名 start
起動条件：サービス停止
監視サービス中で、ロカールサーバは、マスタサーバであれば、及びhadoopのプロセス落ちったら、
hadoopプロセスを立ち上げる
マスタサーバの判定条件：
sleepしてある程度間隔をあけてループするようにする
#mkdir -p /etc/daemon/monitor-hadoop
#cd /etc/daemon/monitor-hadoop
#vi run
#!/bin/sh
VIRTUAL_IP=10.0.10.200
WAIT_TIME=1
PID=/var/run/keepalived.pid
while true; do
run_level=`runlevel|gawk '{print $2}'`
if [ "$run_level" = "2" -o "$run_level" = "3" -o "$run_level" = "5" ]; then
echo "the run level is $run_level,service and process checking ..."
else
echo "the run level is $run_level,no checking" | logger
svc -x /service/monitor-hadoop
exit;
fi
# check the service of drbd
drbd_status=`service drbd status | grep "loaded OK" |awk -F ' ' '{print $4}'`
if [ "$drbd_status" = "OK;" ]; then
echo "drbd is up"
else
service drbd start
fi
# check the service of keepalived
if [ -f $PID ]; then
if kill -0 `cat $PID` > /dev/null 2>&1; then
echo "keepalived is up"
else
echo "keepalived is down,it will be started"
service keepalived start
fi
else
echo "keepalived is down,it will be started"
service keepalived start
fi
# check the processes of hadoop
if [ -z `ps -ef|grep keepalived-master|grep -v grep|gawk '{print $1}'` ]; then
f_virtual_ip=`ip addr show eth1|grep $VIRTUAL_IP|awk -F ' ' '{print $1}'`_$VIRTUAL_IP
if [ $f_virtual_ip = "inet_$VIRTUAL_IP" -a -d /mnt/drbd0/hadoop ]; then
RES=(`/usr/java/latest/bin/jps | grep -v Jps | gawk '{print $2}' | sort`)
f_namenode=false
f_jobtracker=false
f_secondary_namenode=false
for j in ${RES[@]}; do
case $j in
"NameNode")
f_namenode=true
;;
"JobTracker")
f_jobtracker=true
;;
"SecondaryNameNode")
f_secondary_namenode=true
;;
esac
done
if ! $f_namenode; then
echo "start namenode ..."
su - hadoop -c "start-hadoop-master.sh namenode"
else
echo "namenode is up"
fi
if ! $f_secondary_namenode; then
echo "start secondarynamenode ..."
su - hadoop -c "start-hadoop-master.sh secondarynamenode"
else
echo "secondarynamenode is up"
fi
if ! $f_jobtracker; then
echo "start jobtracker..."
su - hadoop -c "start-hadoop-master.sh jobtracker"
else
echo "jobtracker is up"
fi
fi
fi
sleep $WAIT_TIME
done
[hadoop@super03 bin]$ chmod +x run
[hadoop@super03 bin]$ vi /home/hadoop/bin/start-hadoop-master.sh
#!/usr/bin/env bash
# Stop hadoop DFS daemons. Run this on master node.
hadoop-config.sh
case $1 in
"namenode")
hadoop-daemon.sh --config $HADOOP_CONF_DIR start namenode
;;
"secondarynamenode")
hadoop-daemons.sh --config $HADOOP_CONF_DIR --hosts masters start secondarynamenode
;;
"jobtracker")
hadoop-daemon.sh --config $HADOOP_CONF_DIR start jobtracker
;;
esac
#chkconfig keepalived off #OS起動するときに、サービスを立ち上げないよう
[hadoop@super03 bin]$ chmod +x /home/hadoop/bin/start-hadoop-master.sh
#chmod +x run
#mkdir -p log/main
#vi log/run
#!/bin/sh
exec setuidgid root multilog t ./main
#chmod +x log/run
リンクを作る
ln -s /etc/daemon/monitor-hadoop /service/
備考
デーモンの停止、開始、状態確認
a.停止させる場合
# svc -d /service/monitor-hadoop
b.開始する場合
# svc -u /service/monitor-hadoop
c.再起動場合
# svc -t /service/monitor-hadoop
d.状態確認
# svstat /service/monitor-hadoop
# svstat /service/monitor-hadoop/log/

システム構成
サーバ二台
それぞれ、node1とnode2を呼ばれる
一、keepalivedの設置
１、必要なものをチェックとインストール
openssl openssl-devel poptパッケージが必要なので、チェックした結果を見て、存在しないなら、インストールする
[root@VM ~]#yum install openssl openssl-devel popt
２、keepalivedのインストール（ソースから）
[root@VM ~]# cd /usr/local/src
[root@VM src]#wget http://www.keepalived.org/software/keepalived-1.1.15.tar.gz
[root@VM src]#tar zxvf keepalived-1.1.15.tar.gz
[root@VM src]#cd keepalived-1.1.15
[root@VM keepalived-1.1.15]# ./configure
[root@VM keepalived-1.1.15]# make
[root@VM keepalived-1.1.15]# make install
３、設定
下記のように設定する
[root@VM keepalived]# vi /usr/local/etc/keepalived/keepalived.conf
global_defs部分がそのままでもいい
vrrp_instance VI_1 {
state BACKUP
interface eth1    # インタフェース
garp_master_delay 5
virtual_router_id 51
priority 100
nopreempt
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.200.50    #仮想IPアドレス
}
notify_master "/usr/local/sbin/keepalived-master"    #マスタ状態になった後に実行させたいシェルスクリプト
notify_backup "/usr/local/sbin/keepalived-backup"    #バックアップ状態になった後に実行させたいシェルスクリプト
notify_fault "/usr/local/sbin/keepalived-backup"    #インタフェースをダウンした後に実行させたいシェルスクリプト
}
後ろ部分要らなくて、全部削除しよう
[root@VM ~]# vi /etc/init.d/keepalived
stop() {
echo -n $"Stopping $prog: "
killproc keepalived
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog
/usr/local/sbin/keepalived-backup   #サービスをダウンにしたときにバックアップになるよう
}
４、サービス登録と起動
[root@VM etc]# ln -s /usr/local/etc/rc.d/init.d/keepalived /etc/init.d/keepalived
[root@VM etc]# ln -s /usr/local/etc/sysconfig/keepalived /etc/sysconfig/keepalived
[root@VM ~]# mkdir /etc/keepalived
[root@VM ~]# ln -s /usr/local/etc/keepalived/keepalived.conf /etc/keepalived/
[root@VM ~]# ln -s /usr/local/sbin/keepalived /usr/sbin/
[root@VM-2 etc]# chkconfig --add keepalived
[root@VM-2 etc]# chkconfig keepalived on
[root@VM-2 etc]# service keepalived start
備考：
node1とnode2同じように設定する
確認方法：ip addr show eth1
二、DRBDの設置
１、インストール（ソースから）
[root@VM ~]# cd /usr/local/src
[root@VM src]#wget http://oss.linbit.com/drbd/8.2/drbd-8.2.6.tar.gz
[root@VM src]#cd drbd-8.2.6
[root@VM src]#make all install
２、同期化用のパーティションの作成
fdiskでディスクからパーティションを作る
[root@VM etc]# fdisk /dev/xvdb    #後ろは、ディスク設備名である
３、コンフィグ設定
[root@VM etc]# vi /etc/drbd.conf
425行をコメントアウトする
# after "r2";
resource "r0" セクション
on amd子セクションが下記の用に設定する
on VM {    #マシンの名前（node1）
device     /dev/drbd0;
disk       /dev/xvdb1;    # ステップで作ったパーティション
address    172.16.0.47:7788;    #ディスク同期化用のIPとポート(node1)
flexible-meta-disk  internal;
}
on VM-2 {  #マシンの名前（node2）
device    /dev/drbd0;
disk      /dev/xvdb1;    # ステップで作ったパーティション
address   172.16.0.48:7788; #ディスク同期化用のIPとポート(node2)
meta-disk internal;
}
467行から全部削除する
此処まで、node1とnode2同じように設置しておく
４、初期化と起動
a.node1の動作
[root@VM etc]# drbdadm create-md r0     #メータ情報の初期化
[root@VM etc]# /etc/init.d/drbd start    #DRBDを起動する
略
(These values are for resource 'r0'; 0 sec -> wait forever)
To abort waiting enter 'yes' [  17]:yes
略
[root@VM etc]# drbdadm -- -o primary all     #プライマリ状態にする
[root@VM etc]# mkfs /dev/drbd0         #ファイルシステムを作る
[root@VM etc]# mkdir /mnt/drbd0        #マウント先ディレクトリを作る
[root@VM etc]# mount /dev/drbd0 /mnt/drbd0 #マウントする
[root@VM ~]# chkconfig --add drbd        #サービスに登録
[root@VM ~]# chkconfig drbd on        #OS起動するときに自動的に起動するように
b.node2の動作
[root@VM-2 etc]# /etc/init.d/drbd start    #DRBDを起動する
[root@VM-2 ~]# chkconfig --add drbd    #サービスに登録
[root@VM-2 ~]# chkconfig drbd on        #OS起動するときに自動的に起動するように
５、手動で切り替え方法
activeサーバで
umount /mnt/drbd0
drbdadm secondary all
他のサーバで
drbdadm primary all
mount /dev/drbd0 /mnt/drbd0
６、備考
standalone状態の解決方法：
node1:drbdadm disconnect resource
node2:drbdadm disconnect resource
activeサーバ:drbdadm connect resource
他のサーバ:drbdadm -- --discard-my-data connect resource
三、hadoopとの組み合わせる
１、hadoopのメータ情報保存先を/mnt/drbd0移行
drbdがactiveサーバに下記のコマンドを実行する
[root@VM drbd-8.2.6]# mkdir /mnt/drbd0/hadoop
[root@VM drbd-8.2.6]# chown hadoop:users /mnt/drbd0/hadoop
[root@VM drbd-8.2.6]# su - hadoop
[hadoop@VM ~]$ mkdir /mnt/drbd0/hadoop/dfs
[hadoop@VM ~]$ rsync -ac 元保存先 /mnt/drbd0/hadoop/dfs
２、設定
[hadoop@VM ~]$vi $HADOOP_CONF_DIR/hadoop-site.xml
  
    dfs.name.dir
    /mnt/drbd0/hadoop/dfs/v19-name
    namenodeのメータ情報の保存先
  
  
    fs.checkpoint.dir
    /mnt/drbd0/hadoop/dfs/namesecondary
    secondarynamenodeの一時メータ情報の保存先
  
  
    fs.default.name
    hdfs://192.168.200.50:9000
    仮想IPをnamenodeのIPとする
  
  
    mapred.job.tracker
    192.168.200.50:9001
    仮想IPをjobtrackerのIPとする
  
３、シェルスクリプトを作る
[hadoop@VM ~]$vi /home/hadoop/bin/stop-hadoop-master.sh    # hadoopユーザとして登録
#!/usr/bin/env bash
# Stop hadoop namenode and jobtracker daemons.  Run this on master node.
hadoop-config.sh
hadoop-daemon.sh --config $HADOOP_CONF_DIR stop namenode
hadoop-daemons.sh --config $HADOOP_CONF_DIR --hosts masters stop secondarynamenode
hadoop-daemon.sh --config $HADOOP_CONF_DIR stop jobtracker
[hadoop@VM ~]$ chmod +x /home/hadoop/bin/stop-hadoop.sh # 該当スクリプトを実行できるように設定する
[hadoop@VM ~]vi $HADOOP_CONF_DIR/masters
localhost    #ローカルにする、止められるように
[root@VM-2 ~]# vi /usr/local/sbin/keepalived-backup
#!/bin/sh
su - hadoop -c "stop-hadoop-master.sh" | logger
umount /mnt/drbd0
drbdadm secondary all
[root@VM-2 ~]# vi /usr/local/sbin/keepalived-master
#!/bin/sh
while :
do
  if [ -d /mnt/drbd0/hadoop ]; then
    su - hadoop -c "stop-mapred.sh;start-all.sh"  | logger
    break
  else
    drbdadm primary all
    mount /dev/drbd0 /mnt/drbd0
    sleep 1
  fi
done
４、試験
a.node1のeth1ダウンする（node1がactiveをしている時）
実行コマンド：ifconfig eth1 down
結果：OK
b.node2のeth1ダウンする(node2がactiveをしている時）
条件：node1のeth1がupになっている
実行コマンド：ifconfig eth1 down
結果：OK
c.node1の再起動する（node1がactiveをしている時）
条件：node2のeth1がupになっている
実行コマンド：reboot
結果：OK
d.node2の再起動する（node2がactiveをしている時）
条件：node1の立ち上げている
実行コマンド：reboot
結果：OK
e.node1のkeepalivedサービスをダウンにする（node1がactiveをしている時）
実行コマンド：service keepalived stop
結果：OK
f.node2のkeepalivedサービスをダウンにする（node2がactiveをしている時）
実行コマンド：service keepalived stop
結果：OK
g.node1のeth0ダウンする（node1がactiveをしている時）
実行コマンド：ifconfig eth0 down
node1のdrbd状態：
m:res  cs            st               ds                 p  mounted     fstype
0:r0   WFConnection  Primary/Unknown  UpToDate/DUnknown  C  /mnt/drbd0  ext2
node2のdrbd状態：
m:res  cs            st                 ds                 p  mounted  fstype
0:r0   WFConnection  Secondary/Unknown  UpToDate/DUnknown  C
hadoop続け操作できる
ifconfig eth0 upすると、drbd状態node2とnode1両方を正常になれる
結果：OK
h.node2のeth0ダウンする（node2がactiveをしている時）
実行コマンド：ifconfig eth0 down
結果：OK
備考：
切り替えの掛かる時間は、３秒ほど、safemodeの時間が場合によって違う

1. 建立备份目录，设置所有者为postgres
2. 修改pgsql_backup.conf文件，设置需要备份的数据库的数据目录database，和备份目录backup
3. 修改数据库的配置文件postgresql.conf文件，修改archive_command = '/path/to/pgsql_backup.sh archive %p %f'
4. 以postgres用户身份建立定期任务，定期执行pgsql_backup.sh xlog
5. 执行pgsql_backup.sh base进行基础备份(之前，最好执行一次vacuumdb -afz)
6. 执行pgsql_backup.sh clean 清除指定时间以前的备份数据


以下是备份脚本pgsql_backup.sh

#!/bin/bash

# 备份PostgreSQL数据库
# 支持以下命令:
#     base:     进行一个基础备份
#     archive:  归档数据库日志(用于设置postgresql.conf中的archive_command参数)
#     xlog:     复制当前部分填充的日志段
#     clean:    删除指定日期之前的备份数据
#

#database=/raid/postgresql/8.1/main
#backup=/data/backup/database

. /etc/admin/pgsql_backup.conf

base()
{
    local v=$(date "+%Y%m%d")
    local d="$backup/base/$v"
    mkdir -p "$d"

#   vacuumdb -afz
    psql template1 -c "select pg_start_backup('$v');"
    (cd "$database"; cp -a $(ls | sed 's/pg_xlog//') "$d")
    psql template1 -c "select pg_stop_backup();"
}

# archive_command = '/raid/bin/pgsql_backup.sh archive %p %f'
archive()
{
    local p="$1"
    local f="$2"

    if [ "$p" = "" ] || [ "$f" = "" ] || [ -f "$backup/archive/$f" ]; then
        return 1
    fi

    mkdir -p "$backup/archive"

    cp -a "$p" "$backup/archive/$f"
}

xlog()
{
    mkdir -p "$database/pg_xlog"
    rsync -a --delete "$database/pg_xlog" "$backup"
}

clean()
{
    local t=$(echo "$1" | grep -E '^[0-9]{4}-[0-9]{1,2}-[0-9]{1,2}$')

    if [ "$t" = "" ]; then
        echo "Timestamp '$1' error"
        return 1
    fi
    
    touch -d "$t" "$backup/base/timestamp"
    echo -n "Clean archived logs before $(date -r "$backup/base/timestamp" +"%Y-%m-%d")? [y/N] "
    read a
    if [ "$a" != "y" ]; then
        return 1
    fi
    
    echo "cleaning..."

    find $backup/archive -mindepth 1 -maxdepth 1 -not -newer $backup/base/timestamp -print -exec rm -rf {} \;
    find $backup/base -mindepth 1 -maxdepth 1 -not -newer $backup/base/timestamp -print -exec rm -rf {} \;

    echo "done."
}


case $1 in
    base)
        base
        ;;
    archive)
        archive "$2" "$3"
        ;;
    clean)
        clean "$2"
        ;;
    xlog)
        xlog
        ;;
    *)
        echo "usage: $0 {base|archive|xlog|clean}"
        exit 1
        ;;
esac

因为有skype的支持，功能还是很黄很暴力的。推荐使用这个。

pgbouncer特点
    *非常低的内存需求（默认连接2K）。
    *数据返回可以分块分段完成，不需要一次返回完整记录集。  
    *前端服务与后端服务器无关，目标数据库可以为不同系统的主机（winodws linux unix 等等）。
    *支持在线热部署。
    *支持在线重新启动/升级不会丢失客户端连接。
    *支持协议V3的唯一，所以后端版本必须> = 7.4。

编译非常简单 ubuntu下，只需要装 aptitude install  libevent-dev
然后正常 configure make make install 就OK了