管理学流派简介(整理)

管理学流派简介

来源: 互联网, 原作者:郭新宇

管理学到今天已发展有许多学派,典型的有:古典学派、人际关系行为学派、社会系统学派、管理过程学派、经验学派、群体行为学派、社会技术系统学派、决策理论学派、经理角色学派、沟通(信息)中心学派、数学学派(管理科学学派)、权变理论学派等等。以下将对管理学各大流派的产生时间、历史背景、代表人物及代表著作、主要观点及贡献、局限性做简单的介绍。

Ⅰ、古典学派

1、泰勒的科学管理理论(1903)

历史背景

19世纪末到20世纪初,在刚刚经历了南北战争的美国,资本主义经济得到了较快的发展。奴隶制的废除南北部的统一、欧洲移民的流入、铁路大规模的修建和农业的发展,使得国内市场迅速扩大;再加上大量吸取英国的资金和技术,这一切都为美国工业技术的迅速发展与资本的积累奠定了基础。在经济危机和激烈的竞争中,资本迅速聚集,垄断组织发展起来,旧的企业管理方式已经不适合新的时代。此外,劳动生产率提高缓慢,工人劳动时间长,强度大,生产效率低下,工人工资很低,劳资关系紧张。此时,泰勒的科学管理理论应运而生。

代表著作

泰勒(Frederick W·Taylor, 1856~1915)的科学管理理论著作较多,主要有:《计件工资》(1895)、《工厂管理》(1903)、《科学管理原理》(1911)以及“在美国国会的证词”(1912)等。其中《科学管理原理》是泰勒的代表作。

主要观点及贡献

科学管理对管理理论体系的形成和发展有着巨大的贡献,具体有以下几方面:

一、时间研究和动作研究形成的作业标准,在泰勒看来是“科学的事实和法则”,劳资双方都必须服从这个标准。时间和动作的研究发现了工人在不增加劳动强度的情况下,能最轻松最有效率地进行作业的方法,至今仍然是企业管理的重要基础。同时,时间和动作的研究也是解决人机关系协调的重要方面,它使得工具和作业环境的标准化、人机系统更和谐、生产效率进一步提高。
二、科学管理理论所提出的任务管理是由科学地规定作业标准、实行标准化、实行激励工资等原理构成的,对今天的企业管理仍然有很大的现实意义。这一思想认为,为了让员工最大限度地发挥身体和精神的能力以达到标准,企业还需要因人而异地给员工安排适当的职务,规定责任和权限。
三、科学管理理论考虑了经济因素对员工的刺激作用,为后来的“行为科学”学派从社会学和心理学等角度来考察企业中“人的关系”提供了一种思路。
四、科学管理认为管理人员与作业人员分别有自己的工作职责,企业的效率的责任应两者分摊,并相互协作。

局限性

科学管理单纯以“经纪人”的假设出发,并以机械的模式来看待员工。泰勒及其追随者认为工人的目的只是为了获得最大限度的工资,并要求工人在生产中绝对服从,忽视了人的心理和人的主动性。 此外,其研究范围也比较狭窄,仅把重点放在企业内部的劳动组织与生产管理,没有解决企业作为一个整体如何经营和管理的问题。

2、法约尔的行政管理理论(1916)

历史背景

20世纪初,泰勒的科学管理理论迅速的传遍的整个欧洲,但其理论对整个企业组织的管理而言,视野狭窄,观点不系统。因此,在当时的欧洲,出现了另一种知识体系,它把重点放在高级管理者的层面上。经典代表是法约尔创建的以大型企业集体管理为研究对象的行政管理理论。

代表著作

法约尔(Henri Fayol,1841~1925)的行政管理理论代表作是《工业管理与一般管理》,这本著作分为两个部分。第一部分讲述管理教育的必要性和可能性,第二部分提出了管理的原则与要素。

主要观点及贡献

法约尔提出了对“经营”和“管理”的划分、管理教育和创立管理理论的必要性、管理的五项职能(即计划、组织、指挥、协调、控制)、管理的十四项原则以及管理工具。行政管理理论是管理理论发展史上的一个里程碑,它第一次系统、全面地概括和阐述了管理的一般原理;第一次明确、系统地划分了管理的职能、原则。其管理理论以大企业的整体作为研究对象,理论实用范围更加普片,为管理理论的形成构建了一个科学的理论框架,成为迄今主流管理学教科书的普遍框架体系。

局限性

法约尔的管理理论没有从动态的角度来研究组织的发展。他的一般管理理论只考察了组织的内在因素和企业的内部管理,没有考察组织同其外在环境的关系,因而不够全面。而且,他关于管理原则的论述中也有不充分、不科学的地方,管理原理过于机械而缺乏弹性。法约尔的一般管理理论同泰勒的科学管理理论都忽视了人性的研究,仍然把人看作是经济人和机械人。

3、韦伯的官僚集权理论(1911)

历史背景

随着工业革命以及工厂制度的发展,工厂以及公司的组织管理问题越来越突出,有学者开始注意到很多企业由于缺乏明确的组织机构系统来进行管理,问题很多,工厂工作时间很长,事故不断,效率极低,工人缺乏训练,雇主不懂得如何刺激工人提高劳动生产率,使得许多国家的经济发展和企业中的劳动生产率远远落后于当时的科学技术成就。因此很多人开始思考。这是学者们思考组织结构在管理中的作用的开始,他们强调组织与体系、公共或法定权力,这便是官僚制度的来源。而韦伯的组织理论也在这个大环境中得以形成与发展。

代表著作

韦伯( Max Weber,1864-1920)在其代表作《社会组织与经济组织理论》和《论官僚制度》中,比较系统地阐述了人们称之为理想的行政组织理论,即官僚制。
韦伯认为,任何组织都必须以某种形式的权力作为基础,没有某种形式的权力,任何组织都不能达到自己的目标。人类社会存在三种为社会所接受的权力:
1. 传统权力:传统惯例或世袭得来;
2. 超凡权力:来源于别人的崇拜与追随;
3. 法定权力:理性——法律规定的权力。
韦伯关于组织中三种合法权力的精辟分析,犹如茫茫大海上的灯塔。随着社会的发展,组织中法定权力的重要性和科学性日益凸显。韦伯对组织管理理论的伟大贡献在于明确而系统地指出理想的组织应以合理合法权力为基础,这样才能有效地维系组织的连续和目标的达成。

局限性

(1)诸多假设的有效性问题。比如说官僚组织结构理论强调人际关系的非人格化,决策者决策时考虑的只能是规章和程序、合理性和效率。在这里,隐含着的一个假设前提是:组织中只存在正式组织的框架,否认人的感情等非正式组织方面的因素对管理者决策的影响。显然,这个假设前提是不能完全成立的。
(2)它过分地强调执行规章制度。过分地强调规章制度会抑制创造力、革新精神。它使得组织的“官僚”们在遵守规章制度的借口下不做与现实不相关问题的决策;不提前做决策;不做其他人会做的决策。其结果,就形成了人们所批评的效率低下的“官僚主义”和“官僚作风”了。

Ⅱ、人际关系行为学派(1933)

历史背景

古典管理理论的杰出代表泰勒、法约尔等人在不同的方面对管理思想和管理理论的发展做出了卓越的贡献,并对管理实践产生深刻影响,但是他们共同的特点是,着重强调管理的科学性、合理性、纪律性,而未给管理中人的因素和作用以足够重视。他们的理论是基于这样一种假设,即社会是由一群无组织的个人所组成的;他们在思想上、行动上力争获得个人利益,追求最大限度的经济收入,即“经济人”;管理部门面对的仅仅是单一的职工个体或个体的简单总和。基于这种认识,工人被安排去从事固定的、枯燥的和过分简单的工作,成了“活机器”。从2O年代美国推行科学管理的实践来看,泰勒制在使生产率大幅度提高的同时,也使工人的劳动变得异常紧张、单调和劳累,因而引起了工人的强烈不满,并导致工人的怠工罢工以及劳资关系日益紧张等事件的出现;另一方面,随着经济的发展和科学的进步,有着较高文化水平和技术水平的工人逐渐占据了主导地位,体力劳动也逐渐让位于脑力劳动,也使得西方的资产阶级感到单纯用古典管理理论和方法已不能有效控制工人以达到提高生产率和利润的目的。这使得对新的管理思想,管理理论和管理方法的寻求和探索成为必要。

代表人物及代表著作

梅奥(George Elton Myao,1880-1949)原籍澳大利亚的美国行为科学家,人际关系理论的创始人,美国艺术与科学院院土,进行了著名的霍桑试验,主要代表著作有《组织中的人》和《管理和士气》。

主要观点及贡献

1、工人是“社会人”而不是“经济人”。梅奥认为,人们的行为并不单纯出自追求金钱的动机,还有社会方面的、心理方面的需要。因此,不能单纯从技术和物质条件着眼,而必须首先从社会心理方面考虑合理的组织与管理。
2、企业中存在着非正式组织。企业中除了存在着古典管理理论所研究的为了实现企业正式组织的作用在于维护其成员的共同利益,使之免受其内部个别成员的疏忽或外部人员的干涉所造成的损失。为此非正式组织中有自己的核心人物和领袖,有大家共同遵循的观念、价值标准、行为准则和道德规范等。梅奥指出,非正式组织与正式组织有重大差别。在正式组织中,以效率逻辑为其行为规范;而在非正式组织中,则以感情逻辑为其行为规范。如果管理人员只是根据效率逻辑来管理,而忽略工人的感情逻辑,必然会引起冲突,影响企业生产率的提高和目标的实现。因此,管理当局必须重视非正式组织的作用,注意在正式组织的效率逻辑与非正式组织的感情逻辑之间保持平衡,以便管理人员与工人之间能够充分协作。
3、新的领导能力在于提高工人的满意度。在决定劳动生产率的诸因素中,置于首位的因素是工人的满意度而生产条件、工资报酬只是第二位的。职工的满意度越高,其士气就越高,从而产生效率就越高。高的满意度来源于工人个人需求的有效满足。 梅奥的人际关系理论克服了古典管理理论的不足,奠定了行为科学的基础,为管理思想的发展开辟了新的领域。

局限性

(1)过分强调非正式组织的作用
(2)过多的强调感情的作用,似乎职工的行动主要受感情和关系支配
(3)过分否定经济报酬、工作条件、外部监督、作业标准的影响

Ⅲ、社会系统学派(1938)

历史背景

1938年正处于行为科学学派的发展初期,人际关系学说的兴起,使管理学者已经开始注意使用社会学、心理学的方法来分析和处理管理问题,注意协调好组织中的人际关系。但在随后形成的社会系统学派看来,梅奥等人的人际关系学说研究的重点只是组织中人与人之间的关系,这种人际关系强调的是行为个体相互之间的关系,并没有研究行为个体与组织之间的关系协调问题。而如果将组织看作是一个复杂的社会系统,要使系统运转有效,则必然涉及到组织中个人与组织间的协调问题。例如个人目标与组织目标之间的协调,这也符合系统论的基本观点,即系统之间的协调。它不仅包括各个子系统之间的协调也包括各个子系统与大系统之间的协调。而当时的管理实践中也暴露出了某些单纯以人际关系学说为理论指导而不能解释的管理问题。正是基于这样的历史背景,社会系统学派得以产生,并将协调组织中个人与组织之间的关系作为其研究的主导方向。以巴纳德组织理论为代表的社会系统学派的现点也奠定了现代组织理论的基础,对管理思想的发展,特别是组织理论的发展产生了深远的影响。

代表人物及代表著作

美国著名的管理学家切斯特·巴纳德(chester Barnard,1886-1961),作为社会系统学派的创始人,在1938年出版了《经理的职能》一书,在这本著作中,他对组织和管理理论的一系列基本问题都提出了与传统组织和管理理论完全不同的观点。

主要观点及贡献

一、组织是一个是由个人组成的协作系统,个人只有在一定的相互作用的社会关系下,同他人协作才能发挥作用。
二、巴纳德认为组织作为一个协作系统都包含三个基本要素:能够互相进行信息交流的人们;这些人们愿意做出贡献;实现一个共同目的。因此,一个组织的要素是:信息交流
三、组织是两个或两个以上的人所组成的协作系统,管理者应在这个系统中处于相互联系的中心,并致力于获得有效协作所必需的协调,因此,经理人员要招募和选择那些能为组织目标的实现而做出最好贡献并能协调地工作在一起的人员。
四、经理人员的作用就是在一个正式组织中充当系统运转的中心,并对组织成员的活动进行协调,指导组织的运转,实现组织的目标。
根据组织的要素,巴纳德认为,经理人员的主要职能有三个方面:
⑴提供信息交流的体系;
⑵促成必要的个人努力;
⑶提出和制定目的。
以巴纳德组织理论为代表的社会系统学派的观点奠定了现代组织理论的基础,对管理思想的发展,特别是组织理论的发展产生了深远的影响,后来的许多学者如德鲁克、孔茨、明茨伯格、西蒙、利克特等人都极大地受益于巴纳德,并在不同方向上所发展。

局限性

巴纳德认为组织的要素只包括人,不包括物和其他要素,所以对组织的研究就转变成对人的研究。巴纳德把财和物排除在组织的组织要素之外,他提出的经理人员的职能没有对财和物管理的职能。

Ⅳ、管理过程学派(1955)

历史背景

在法约尔之后,哈罗德·孔茨(Harold Koontz)和西里尔·奥唐奈(Cyril O’Donnell)在仔细研究这些管理职能的基础上,将管理职能划分为计划、组织、认识、领导和控制五项。孔茨利用这些管理只能对管理理论进行分析、研究和阐述,最终得以建立起管理过程学派。

代表人物及著作

哈罗德·孔茨和西里尔·奥唐奈都是管理过程学派的主要代表人物,其代表作为两人合著的《管理学》。

主要观点及贡献

管理过程学派的主要特点是将管理理论同管理人员所执行的管理职能,也就是管理人员所从事的工作联系起来。他们认为,无论组织的性质多么不同(如经济组织、政府组织、宗教组织和军事组织等),组织所处的环境有多么不同,但管理人员所从事的管理职能却是相同的,管理活动的过程就是管理的职能逐步展开和实现的过程。因此,管理过程学派把管理的职能作为研究的对象,他们先把管理的工作划分为若干职能,然后对这些职能进行研究,阐明每项职能的性质、特点和重要性,论述实现这些职能的原则和方法。管理过程学派认为,应用这种方法就可以把管理工作的主要方面加以理论概括并有助于建立起系统的管理理论,用以指导管理的实践。
管理过程学派相对于其他学派而言,是最为系统的学派。他们首先从确定管理人员的管理职能入手,并将此作为他们理论的核心结构。孔茨认为管理学这样分类具有内容广泛、能划分足够多的篇章、有利于进行逻辑性分析等优点。该学派对后世影响很大,许多管理学原理教科书都是按照管理的职能写的。 管理过程学派确定的管理职能和管理原则,为训练管理人员提供了基础。把管理的任务和非管理的任务(如财务、生产以及市场交易)加以明显地区分,能使经理集中于经理人员的基本工作上。管理过程学派认为,管理存在着一些普通运用的原则,这些原则是可以运用科学方法发现的。管理的原则如同灯塔一样,能使人们在管理活动中辨明方向。

局限性

一、管理过程学派所归纳出的管理职能不能适用所有的组织。所归纳出的管理职能通用性有限,对静态的、稳定的生产环境较为合适,而对动态多变的生产环境难以应用。
二、管理过程学派所归纳的职能并不包括所有的管理行为。
三、在管理者日常管理中,一定是先有了目标和组织,然后进行管理,而不是先有一套典型的职能,能够到处运用到不同的组织中去。

Ⅴ、经验学派(19世纪60年代)

历史背景

十九世纪五六十年代是美国经济空前发展的时期,五十年代工业生产年平均增长率为4%,从1961年到1969年,美国经济持续出现了106个月的高速增长,所以六十年代是美国的繁荣时代。伴随着良好的宏观经济形式,一大批大企业纷纷崛起并取得了良好的效益。这些公司在取得成功之后,开始总结自身成功的经验;在结合当时兴起的研究管理的浪潮,将这些实践经验归纳总结,进而形成了经验学派。

代表人物及代表著作

经验学派理论以德鲁克(Peter F.Drucker,1909~2005)的《有效的管理者》、欧内斯特·戴尔(Ernest Dale,1919~ )的《伟大的组织者》以及埃尔弗雷德·斯隆和通用汽车对组织和经营管理的贡献为代表。

主要观点及贡献

经验学派认为管理学就是研究管理经验,认为通过对管理人员在个别情况下成功的和失败的经验教训的研究,会使人们懂得在将来相应的情况下如何运用有效的方法解决管理问题。因此,这个学派的学者把对管理理论的研究放在对实际管理工作者的管理经验教训的研究上,强调从企业管理的实际经验而不是从一般原理出发来进行研究,强调用比较的方法来研究和概括管理经验。 经验学派在一定程度上反映出现代社会产生与现实管理实践的客观要求,通过大量的案例与实例的分析研究,为管理者提供管理的思路和经验借鉴。

局限性

经验主义学派由于强调经验而无法形成有效的原理和原则,无法形成统一完整的管理理论,管理者可以依靠自己的经验,而无经验的初学者则无所适从。而且,过去所依赖的经验未必能运用到将来的管理中。由于组织环境一直处于变化之中,过分地依赖未经提炼的实践经验和历史来解决管理问题是无法满足需要的。

Ⅵ、群体行为学派(1944)

历史背景

十九世纪二十年代前后,一方面工人日益觉醒,工会组织蓬勃发展,工人组织起来对雇主进行斗争;另一方面,经济和科学技术的发展以及周期性经济危机的加剧,使得企业主感到但存用传统管理理论已不能有效地控制工人、提高劳动生产率和利润。有的管理学家和心理学家也意识到,社会化大生产的发展需要有一种与之相适应的思维来进行管理。霍桑试验以后人们开始关注组织的行为,人际关系学派也逐渐兴起。
德国学者卡特·莱温(Kurt Lewin,1890~1947)于1944年首先提出“群体动力学”的概念来描述团体中人与人相互接触、影响所形成的社会关系。 美国管理学家克里斯· 阿吉里斯(Chris Argyris)在 1957年发表的《个性与组织:互相协调的几个问题》一文中提出了所谓的“不成熟—成熟交替循环”的模式。

主要观点及贡献

群体行为学派关心的主要是一定群体中的人的行为,而不是一般的人际关系和个人行为,它以社会学、人类文化学、 社会心理学为基础。 这个学派着重研究各个群体的行为方式,从小群体的文化和行为方式到大群体的行为特点。其主要理论为:有关信息交流的理论、群体及其相互关系的相关理论以及有关群体间竞争和冲突的理论。 该理论对今后的群体行为研究产生了相当大的影响。

局限性

阿吉里斯认为传统的组织鼓励个人不要承担责任而是顺从,然而调查表明事实是组织既没有支持服从也没有鼓励。同时,由于工作的性质和采用的领导方式存在这差异,不应该把组织都看成千篇一律的。此外,由于人们在个性和工作能力上是存在着差异的,所以对群体的一致要求可能导致许多人主动或者被动失业。

Ⅶ、社会技术系统学派(19世纪70年代)

历史背景

第二次世界大战后,世界的政治经济形势更加错综复杂,从七十年代开始主要资本主义国家进入滞涨时期,企业家和管理理论的工作者们开始试图找到解决的办法。加之,二战后出现了第三次科技浪潮,科学技术发展所引起的一系列生产力的、生产关系的、社会的新问题,给社会科学的发展及研究方法带来了一系列新变化。这时,社会技术系统学派在战后政治经济形势和科学技术迅猛发展的背景下得以产生。

代表人物及代表著作

社会技术系统学派是由特里斯特(E.L.Trist)、埃默里、赖斯、班福斯等人在伦敦的塔维斯托克人际关系研究所的组织下,对英国达勒姆煤矿采煤现场的作业组织和印度艾默达巴德纺织厂进行研究的基础上发展形成,后来又由美、英等国管理人士进一步加以发展。
社会技术系统学派的主要代表作有:《组织的选择》、《长壁采煤法的某些社会和心理影响》、《生产率和社会组织》、《社会—技术系统》、《组织环境的因果机构》等。

主要观点及贡献

通过对英国煤矿中长壁采煤法生产问题的研究,发现单只分析企业中的社会方面是不够的,还必须注意其技术方面。企业中的技术系统(如机器设备和采掘方法)对社会系统有很大的影响。个人态度和群体行为都受到人们在其中工作的技术系统的重大影响。因此,必须把企业中的社会系统同技术系统结合起来考虑,而管理者的一项主要任务就是要确保这两个系统相互协调。

局限性

社会技术系统学派的大部分著作都集中于研究科学技术对个人、对群体行为方式以及对组织方式和管理方式的影响,因此,特别注重于工业工程、人机工程等方面的研究,但这一研究方向对于引领未来的新兴产业以及衡量经济发达程度的第三产业缺乏研究。

VIII、决策理论学派(1974)

历史背景

决策理论学派第二次世界大战后,随着现代生产和科学技术的高度分化与高度综合,企业的规模越来越大,特别是跨国公司不断地发展,这种企业不仅经济规模庞大,而且管理十分复杂。同时,这些大企业的经营活动范围超越了国界,使企业的外部环境发生了很大的变化,面临着更加动荡不安和难以预料的政治、经济、文化和社会环境。在这种情况下,对企业整体的活动进行统一管理就显得格外重要了。 决策理论的星期,是同战后西方资本主义企业环境的变化和自身的变化发展分不开的。

代表人物及代表著作

决策理论学派的主要代表人物是获1978年度诺贝尔经济学奖的赫伯特·亚历山大·西蒙(Herbert Alexander Simon)。西蒙虽然是决策学派的代表人物,但他的许多思想是从巴纳德中吸取来的,他发展了巴纳德的社会系统学派,并提出了决策理论,建立了决策理论学派,形成了一门有关决策过程、准则、类型及方法的较完整的理论体系,主要著作有《管理行为》、《组织》、《管理决策的新科学》等。 詹姆斯·马奇(James G.March),1953年在美国耶鲁大学获得博士学位,以后在卡耐基工艺学院任教。1964年成为加利福尼亚大学的社会科学学院的首任院长,1970年成为斯坦福大学的管理学教授。其代表作有《组织》(与西蒙合著,1958)、《企业的行为理论》(与赛叶特合著,1963)。

主要观点及贡献

一、决策贯穿管理的全过程,决策是管理的核心。西蒙指出组织中经理人员的重要职能就是作决策。他认为,任何作业开始之前都要先做决策,制定计划就是决策,组织、领导和控制也都离不开决策。
二、系统阐述了决策原理。西蒙对决策的程序、准则、程序化决策和非程序化决策的异同及其决策技术等作了分析。西蒙提出决策过程包括4个阶段: 搜集情况阶段; 拟定计划阶段; 选定计划阶段; 评价计划阶段。 这四个阶段中的每一个阶段本身就是一个复杂的决策过程。
三、在决策标准上,用“令人满意”的准则代替“最优化”准则。以往的管理学家往往把人看成是以“绝对的理性”为指导,按最优化准则行动的理性人。西蒙认为事实上这是做不到的,应该用“管理人”假设代替“理性人”假设,“管理人”不考虑一切可能的复杂情况,只考虑与问题有关的情况,采用“令人满意”的决策准则,从而可以做出令人满意的决策。
四、一个组织的决策根据其活动是否反复出现可分为程序化决策和非程序决策。经常性的活动的决策应程序化以降低决策过程的成本,只有非经常性的活动,才需要进行非程序化的决策。 从管理职能的角度来说,决策理论提出了一条新的管理职能。针对管理过程理论的管理职能,西蒙提出决策是管理的职能,决策贯穿于组织活动全部过程,进而提出了“管理的核心是决策”的命题。由于决策理论不仅适用于企业组织,而且适用于其他各种组织的管理,具有普遍的适用意义。决策理论还首次强调了管理行为执行前分析的必要性和重要性。在决策理论之前的管理理论,管理学家的研究重点集中在管理行为的本身的研究中,而忽略管理行为的分析,然而西蒙把管理行为分为“决策制定过程”和“决策执行过程”,并把对管理的研究的重点集中在“决策制定过程”的分析中。

局限性

决策理论重视程序化的决策,而对于非程序化的、具有创新性质和战略性质的非程序化决策则探讨不充分。另外,决策理论重视组织内部的平衡,重视提高组织的“效率”,而对于组织外部平衡,即组织对外部环境的适应性则未作充分探讨。

Ⅸ、经理角色学派(19世纪70年代)

历史背景

管理学从其产生到十九世纪七十年代,管理学家们研究了许多的理论问题和方法问题,产生了各式各样的理论,学派林立。但是,直到五六十年代,才有很少一部分学者开始认真研究管理者的实际活动;直到七八十年代,这些研究工作才开始受到一些重视,此时西方管理理论与管理实践之间存在相当大的差距。对管理学者来说,要想进一步发展管理理论和管理技术,就必须了解管理实际。七十年代,以亨利·明茨伯格为代表的经理角色学派诞生了。

代表人物及代表著作

加拿大管理学家亨利·明茨伯格(Henry Mintzberg,1939~ )是该学派的主要代表人物, 1968年获得美国麻省理工大学斯隆管理学院博士学位,长期在麦吉尔大学任教,现为该校管理学教授。1973年出版的《经理工作的性质》是明茨伯格的主要代表作,也是经理角色学派最早出版的经典著作。

主要观点及贡献

经理角色学派理论来源于对传统管理职能的认识,明茨伯格认为传统的管理职能和人们所认识的管理工作大不一样,传统的管理职能研究不能全面地理论结合实际,没有对经理的工作进行深入的研究,缺乏有效的证据,不能反映出经理工作的真正面貌和实质。 经理角色理论是在现代企业组织理论基础上发展起来的,是在经营权与所有权分离以后经理成为一种职业的产物。该理论不仅对我们理解经理人的角色、工作性质、职能、经理的培养具有重要意义,而且还对如何提高经理工作效率,尤其是对改革我国传统的经营管理体制(如激励机制、监控机制、决策机制)具有重要的现实意义。由于经理工作极为重要,权力又非常之大,其行为的影响又非常深远,因此如何建立既不影响经理发挥职能,又能有效发挥其积极性、创造性,同时又能约束其滥用职权的制度,就是我国目前建立现代企业制度的当务之急。过去的经验表明,我们旧的管理体制中对经理的复杂角色欠缺全面的考虑,因此经理的角色未能得到充分地发挥。经理角色理论为我们在这方面的改革提供比较好的理论。

局限性

经理角色学派对管理职能的归纳仍然是有问题的。首先,经理角色学派其得出的管理十种角色靠归纳得出,对管理者的调查由于数量较少而受到怀疑;其次,明茨伯格所得出的管理行为是否包含了所有的管理行为很值得怀疑。

Ⅹ、沟通(信息)中心学派

历史背景

二战时期,英国为解决国防需要而产生“运筹学”,发展了新的数学分析和计算技术。这些成果在战后应用于管理工作并与行为科学平行发展而最终产生了“管理科学理论”。 自十九世纪六十年代末申农创立信息理论以来,由于信息技术的迅速、高度发展和广泛基础和应用领域,使信息理论得到了重大的发展。 沟通(信息)中心学派作为“管理科学”理论与信息科学理论的结合,将信息沟通介入管理学的研究领域,在两个理论同步发展的背景下得以形成与发展。

代表人物及代表著作

美国著名组织行为学家、心理学家、斯坦福大学教授哈罗德·J·李斯特(H.J.Leavitt)是该学派的主要代表人之一,他从组织群体行为与信息沟通的角度研究管理学。主要代表作《沟通联络类型对群体绩效的影响》论述了他有关信息沟通与组织行为的主要思想。 此外,还有申农(Claude Shannou)的《通信的数学理论》以及申农和韦弗(Warren Weaver)合著的《沟通联络的数理统计理论》。

主要观点及贡献

沟通(信息)中心学派同决策理论学派关系密切,它主张把管理人员看成为一个信息中心,并围绕这一概念来形成管理理论。这一学派认为,管理人员的作用就是接收信息、贮存与发出信息;每一位管理人员的岗位犹如一台电话交换台。 沟通(信息)中心学派强调计算机技术在管理活动和决策中的应用,强调计算机科学同管理思想和行为的结合。大多数计算机科学家和决策理论家都赞成这个学派的观点。

局限性

沟通(信息)学派的观点主张把管理人员看成为一个信息中心,忽视了管理人员的其他角色,将管理活动在一定程度上简单化了。此外,由于强调计算机技术在管理活动和决策中的应用,使得这一理论不适用于对落后国家的自然经济,也不适用于部分个体经营者和低级生产经营的简单经营管理需要以及松散组织的简单管理活动。

Ⅺ、管理科学学派

历史背景

管理科学学派的理论渊源,可以追溯到本世纪初泰勒的”科学管理”。”科学管理” 的实质;是反对凭经验、直觉.主观判断进行管理,主张用最好的方法、最少的时间和支出,达到最高的工作效率和最大的效果。 第二次世界大战时期,为解决国防需要产生了”运筹学” ,发展了新的数学分析和计算技术,例如:统计判断、线性规划、排队论、博弈论、统筹法、模拟法、系统分析等。这些成果应用于管理工作就产生了”管理科学理论”。

代表人物及代表著作

一战期间,英国的兰彻斯特(F.W.Lanchester)在1915年就把数学定量分析法应用于军事,发表过关于人力和火力的优势与军事胜利之间的理论关系的文章,为西方管理科学学派的代表人物之一。其代表作包括《现代生产管理》一书,以及1975年根据本书加以改写的《生产管理基础》。 一战期间,英国军需部并成立了防空试验组,由生理学家希尔(A.V.Hill) 上尉(以后成为教授)领导,应用数理分析方法来运用于防空武器。希尔被人称为运筹学研究的创始人之一。 从20世纪50年代开始,出现了一批管理科学(运筹学)方面的教科书:韦斯特·丘奇曼、拉塞尔·阿考夫、伦纳德·阿诺夫三人合著的《运筹学入门》 ;爱德华·鲍曼和罗伯特·费特两人台著的《生产管理分析》、塞缪尔·里奇蒙的《用于管理决策的运筹学》, 以及许多关于线性规划、决策模型、培欣决策法、对策轮方面的书籍。

主要观点及贡献

管理科学学派力求减少决策的个人艺术成分。依靠建立一套决策程序和数学模型以增加决策的科学性。他们将众多方案中的各种变数或因素加以数量化,利用数学工具建立数量模型研究各变数和因素之间的相互关系,寻求一个用数量表示的最优化答案。决策的过程就是建立和运用数学模型的过程。他们认为各种可行的方案均是以经济效果作为评价的依据。例如成本、总收入和投资利润率等。该学派广泛地使用电子计算机。现代企业管理中影响某一事务的因素错综复杂,建立模型后,计算任务极为繁重,依靠传统的计算方法获得结果往往需要若干年时间,致使计算结果无法用于企业管理。电子计算机的出现大大提高了运算的速度,使数学模型应用于企业和组织成为可能。 管理科学学派理论使复杂的、大型的问题有可能分解为较小的部分,更便于诊断、处理;制作与分析模式必须重视细节并遵循逻辑程序,这样就把决策置于系统研究的基础上,增进决策的科学性;这一理论也有助于管理人员估价不同的可能选择,如果明确各种方案包含的风险与机会,便更有可能做出正确的选择。

局限性

首先,管理科学学派的适用范围有限,并不是所有管理问题都是能够定量的,这就影响了它的使用范围。例如,有些管理问题往往涉及许多复杂的社会因素,这些因素大都比较微妙,难以定量,当然就难以采用管理科学的方法去解决。 其次,实际解决问题中存在许多困难。管理人员与管理科学专家之间容易产生隔阂。实际的管理人员可能对复杂、精密的数学方法很少理解,无法做出正确评价。而另一方面,管理科学专家一般又不了解企业经营的实际工作情况,因而提供的方案不能切中要害,解决问题。这样,双方就难以进行合作。 此外,采用此种方法大都需要相当数量的费用和时间。由于人们考虑到费用问题,也使它往往只是用于那些大规模的复杂项目。这一点,也使它的应用范围受到限制。

Ⅻ、权变理论学派

历史背景

七十年代的美国,社会不安,经济动荡,政治骚动,达到空前的程度,石油危机对西方社会产生了深远的影响,企业所处的环境很不确定。但以往的管理理论,如科学管理理论、行为科学理论等,主要侧重于研究加强企业内部组织的管理,而且以往的管理理论大多都在追求普遍适用的、最合理的模式与原则,而这些管理理论在解决企业面临瞬息万变的外部环境时又显得无能为力。正是在这种情况下,人们不再相信管理会有一种最好的行事方式,而是必须随机制宜地处理管理问题,于是形成一种管理取决于所处环境状况的理论,即权变理论,“权变”的意思就是权宜应变。

代表人物及代表著作

弗雷德·卢桑斯(Fred Luthans,1939~ ),美国尼伯拉斯加大学教授,于1973年发表了《权变管理理论:走出丛林的道路》、1976年发表了《管理导论:一种全变学》,成为权变学派的代表人物之一。 杰伊·洛希(Jay W.Lorch),美国哈佛大学人际关系学教授,与保罗·罗杰·劳伦斯(P.R.Lawrence)合写了《组织和环境》与《组织结构与设计》,因此被称为权变管理学派创始者。
佛里蒙德·卡斯特(F.E.Kaster)与詹姆斯·罗森兹韦克(J.E.Rosenzweig)都是美国华盛 顿大学管理学教授、权变理论学派代表人物,于1970年共同出版了《组织与管理—系统与权变的观点》,此书成为了权变管理学派的代表作之一。
汤姆·伯恩斯(Tom Burns)与斯托克是最早运用权变管理思想来研究管理问题的人。他们于1961年合著了《革新的管理》一书,又联合发表了《机械式和有机式的系统》。
钱德勒(Alfred Chandler)于1962年出版了《战略与结构一书》,书中强调了不同条件下的多种组织方案。
佛莱德·E·菲德勒(Fred E.Fiedler)从1951年起由管理西里学和实证环境分析两方面研究领导学,提出了“权变领导理论”;认为任何领导形式都可能是有效的,关键关键在于领导者必须与环境相适应。
琼·伍德沃德(Joan Wood Ward,1916~1917)于1965年出版《工业组织:理论与实践》,证明了企业组织的技术分系统与结构分系统具有直接的相互关系。

主要观点及贡献

权变理论学派认为,在企业管理中要根据企业所处的内外条件随机应变,没有什么一成不变、普遍适用的“最好的”管理理论和方法。该学派是从系统观点来考察问题的,它的理论核心就是通过组织的各子系统内部和各子系统之间的相互联系,以及组织和它所处的环境之间的联系,来确定各种变数的关系类型和结构类型。它强调在管理中要根据组织所处的内外部条件随机应变,针对不同的具体条件寻求不同的最合适的管理模式、方案或方法。
权变理论为人们分析和处理各种管理问题提供了一种十分有用的方法。它要求管理者根据组织的具体条件,及其面临的外部环境,采取相应的组织结构、领导方式和管理方法,灵活地处理各项具体管理业务。这样,就使管理者把精力转移到对现实情况的研究上来,并根据对于具体情况的具体分析,提出相应的管理对策,从而有可能使其管理活动更加符合实际情况,更加有效。同时,权变学派首先提出管理的动态性,人们开始意识到管理的职能并不是一成不变的,以往人们对管理的行为的认识大多从静态的角度来认识,权变学派使人们对管理的动态性有了新的认识。

局限性

虽然权变学派的管理学者采取案例研究的方法,通过对大量案例的分析,从中概括出若干基本类型,试图为各种类型确认一种理想的管理模式,但却始终提不出统一的概念和标准。权变理论强调变化,却既否定管理的一般原理、原则对管理实践的指导作用,又始终无法提出统一的概念和标准,每个管理学者都根据自己的标准来确定自己的理想模式,未能形成普遍的管理职能,权变理论使实际从事管理的人员感到缺乏解决管理问题的能力,初学者也无法适从。

 

1苏勇. 当代西方管理学流派. 上海:复旦大学出版社,2007
2.斯图尔特·克雷纳. 管理百年. 海口:海南出版社,2003
3.管理学百年1

IT行业管理结语:

在IT行业,创新为重要生产力。它不仅仅要求产品创新、商业模式创新,也包括了组织创新。IT公司的管理模式更需要以人为本,尊重个性发展,加强沟通协作,充分认识到“社会人”的角色。重点学习实践的管理理论包括人际关系行为学派、社会技术学派、权变理论学派。

研究生入学第一天,聊一聊为什么IT男选择了“管理学”

    2017年9月9日,研究生入学第一天。 聊一聊,为什么要入学,为什么选择了“工商管理“这一个专业。
    大学毕业已经十一载了,现在的我,成了IT界的老兵,经验丰富,而且仍然善战。这几年职位的变化,屁股在动,但却没有决定好脑袋。两年前独立负责事业部,人、事、财、物、信息,纷繁芜杂的内容,特别是内部资源冲突、外部合作资源、再加上个人人际关系管理能力的落后,这种全新的思维方式把我彻底摧垮掉了,整个事业部的发展也陷入了困境。
    后来事业部解散,我重新回归到技术部,高级技术专家岗位。在这擅长的工作领域,给了我足够时间来思考着新的学习方向。当今社会,已经不再强调短板理论,而更希望每个人能充分发挥自己的长板,建立自己具备绝对天赋的技能竞争力。所以,我一直在纠结,个人未来的发展是继续在计算机专业领域深入研究,完成自己一直未变的职业规划:“(移动)互联网全面的解决方案”,还是去补充学习自己的短板,了解一些管理和人际管理的知识。
    最后让我决定学习管理学专业,更确切的说是管理心理学方向,缘由来自于《沙因*组织行为学》中提到的霍桑实验现象:
> 但是最高产量和最低产量的生产者却是社交孤立者,不属于任何一个团体。那么显然,与个人产量联系最紧密的因素是员工的社交成员身份,而不是他们的先天能力。
> 员工的工作绩效在很大程度上不是依赖于员工个人,而是依赖于员工所处的社会关系网络。
    历史以来,我一直以拔尖者为骄傲,在技术管理方式中,我也尽力将自己塑造成一个无法赶超的,“神一样的技术牛人”。但这种影响力非常具有局限性,从单纯的技术人员管理方面,可以起到了很好的作用,但这种影响无法扩展到其他部门、也无法进行上级汇报。甚至于,这种“神一样的存在”对公司IT群体也是一种伤害——优秀的单兵作战能力,反衬出了IT规模化组织背后的效率低下。
    “有能力,也是一种错”。 这句话很讽刺,现在是真的懂了。所以,对研究生专业的选择答案也就有了。
    完成组织行为学、权变的情景管理这几门基础管理课程学习,通过基础的管理理论及模型,来熟练运用IT团队领域的矩阵项目管理、敏捷管理、DevOps工具等等,这才是能够真正提高IT团队生产效率的最有效工具!
    立个碑,埋葬掉既往的一切光环。
    立个碑,离开舒适区,开始新的蜕变。

对男护士的歧视 –《组织行为学》

书目: 《组织行为学》 ISBN: 9787509611074
章节: 第二章 工作场所中的多样性和不平等性

 

案例分析:一个新护士

当乔·罗布尔斯( Joe Robles)和他的指导老师眺望窗外一所州立小学校的校园时,乔对老师说:“不要以为我疯了”。乔正在读大大学二二年级,到目前为止,无论是在学校内还是在校外活动方面,所有的事情对于乔来说都非常顺利。他不仅参加了几项体育比赛,而且最近他还在校园话剧中领衔演主角。乔通过做割草工和花园修剪员来支付自己的学费。
“就整个学校来说,你是最优秀的年轻人之一,”他的老师,马里斯·丹尼( Marisa Dennehy)思考了一下对他说。
“为什么我会认为你疯了呢?”马里斯问道
“是这样,”乔说,“我知道我自己肯定不适合做传统的工作。但我发现我对护士工作越来越感兴趣。”
“你是指的医学院?”马里斯问道,“我相信你会成为一个好医生。”
“每个人都这么说,”乔低声说,“但是正如我说的,我是想成为一名护士,而不是医生。我好像还没告诉过您,我的叔叔和姐姐都有很严重的病。因此这几年中,我在医院里花了很多时间。我经常和医生护士聊些他们的工作。医生的工作让我觉得太过于医学化,他们诊断开处方,事实也的确如此。但是,护士工作是持续不断的、耐心的护理——这也正是我真正感兴趣的地方。我知道这不符合传统,但是我为什么不从事一个自己真正喜欢的工呢?”

案例思考题
1.假设你处在马里斯的位置上,当乔向你来咨询时,你会给他提供哪些建议?为什么会给他这些建议呢?
2.如果乔决定要从事护士工作,他会遇到哪些问题?他怎样才能克服这些问题呢?

 

思考解答:
无法避免,案例中出现了两种歧视,我也同样会产生这种歧视。
  1. 社会对护士职业歧视。 护士是一个低级职位,不需要高学历。在中国,卫校的学历是中专,或者大专,那是专业生产护士的地方。而医生至少是本硕连读出来的高学历人才。在岗位贡献上,护士是一个不可或缺的岗位,优秀的护士作为医生的左右手,能给病人带来耐心的护理,愉快的心情,但和医生的开刀问诊相比,始终是一项辅助工作。护士也经常会受到病人的抱怨、责骂,这也是职业被严重歧视的重要原因。
  2. 护士职业对男性的歧视。和女性相比,男性更没有耐心,在细心程度上也难以与女性相比。社会并不认同男性从事如此细节、服务化的行业,病人也并不认同男性能做好这一个职业。
在我的个人经历中,存在过类似的经历。那是在初中接近毕业时,当时两个选择,一是考入高中,然后进行考大学;另一各选择是提前报名职业教育,进入中专职业化学习。当时由于家庭以及经济原因,我选择了报考中专,希望进入师范类院校。我将这个选择告诉了班主任老师,老师苦口婆心的劝了我很久,但并没有打动我这执拗的疯了的决定。我还是提交了中专志愿表。后来的结果,老师私下把我的表扣押了,也没有通知我参加必须的中专体检、申报流程,我被迫只能进入高中,然后开始我后面的大学生活。衷心感谢老师的决定,否则现在的我应该在某一个乡村小学做一个数学老师,能贡献一方教育事业,但和现在的职业快乐相比,确实很小。
基于对男护士的歧视,作为马里斯,我不会同意乔转向到这个职业。对乔的几个引导点:
  1. 乔,是一个优秀的学生,应该有远大的职业理想,社会抱负;
  2. 每一个职业对社会都是有贡献的,护士有,马路清洁工也有,但社会责任需要乔,在更高端的领域付出更多;
  3. 鲁迅先生弃笔从文,因为文能影响到全中国4万万人民。而护士职业,可能没有可行的职业规划服务于整个社会,而只能服务于小众群体;
  4. 乔目前的职业选择,源于生活的变故,产生的冲动。通过心理咨询,可以挖掘并提醒乔更深层的职业想法。
如果乔继续坚持,希望从事护士工作,通过学习,在职业能力模型上,乔可以具备足够的能力以及态度。乔遇到的最大的问题,就在于“男护士”的歧视。来自社会的,来自同僚的,来自病人的,都是职业压力。
我并不能给到他如何解决这些歧视的意见。我将寻找一个行业专家,与乔一起,定义一个长期的职业规划目标,比如护士长、护理教育工作者等,特别是需要找到一个能够形成全社会贡献的职业发展目标。然后告诉他,专注于这个职业目标,忽略掉关于歧视的一切,行动!
最后,支持和祝福也能给他一些安慰和帮助。

关于道德伦理的决策 –《组织行为学》

书目: 《组织行为学》 ISBN: 9787509611074
章节: 第一章 工作中的人们的行为 — 侧重道德伦理

案例分析: 决策,决策

    “自从我毕业走进这真实的’世界’,从没有人告诉过我事情会这么复杂。”托尼·冈萨雷斯( Tony Gonzales)叹息道,他经常思考这样的问题。“我不认为自己是极为拘谨的人。容让别人,别人也会容让你,早已成为我的座右铭。因此,我总觉得在处理问题时要规规矩矩的,而不要自找麻烦。并且我也没试图做过取悦老板或类似的事。”冈萨雷斯说道,然后接着自言自语道:“但是我肯定遇到麻烦了,在这种见不到收获的情形下,你会怎么做呢?”

在许多方面,冈萨雷斯说到的不见收获的情形是很准确的说法。首先,工作很好—但是这仅仅意味着未来前景还可以。冈萨雷斯毕业后加入的 Marschand公司有一项政策:每一位员工都必须从基层干起。 Marschand公司的想法是,如果高层员工花一定的时间从底层做起,他们会更了解公司的情况,这样工作起来会更有成效。冈萨雷斯本人是非常赞同公司这项政策的。

冈萨雷斯把自己的职业目标锁定在财务方面,所以他一开始就从会计部门的小职员做起。在这个部门中有几个和他年龄相仿的职员。他们都被指派协助像记录管理员和高级会计师这样的高层员工。尤其高级会计师被委任了很多的权力,因此,他们在很大程度上是独立的。而部门主管沙伦·奥得哈姆( Sharon oldham)偶尔会忽略这一点。奥得哈姆是个勤奋、认真的主管。她只有在工作负担很重的时候,才会让本部门的其他人帮她。尽管冈萨雷斯很坦诚地与奥得哈姆谈过几次,但是觉得自己对她一点儿也不了解。

这就是问题的所在—“该向谁负责?该去信任谁?”冈萨雷斯不停地在想这些问题。因为他十分肯定他发现了一件见不得人的事。在协助高级会计师约翰·威克瑟姆(John wixmire)工作期间,冈萨雷斯注意到威克瑟姆看上去极为紧张,并且总试图对自己写的资料遮遮掩掩。那天是发工资的日子,威克瑟姆写员工领取工资的时间表。冈萨雷斯一直努力不去注意威克瑟姆奇怪的举止。当威克瑟姆把椅子转过来要说些什么时,不小心把一些工资单散落到地板上。冈萨雷斯习惯性地去捡地上的纸。在捡工资单时,他瞥了一眼却看到在工资单的最上面的一个新名字—威廉·本尼斯。
“在这儿工作的人谁也不叫这个名字,”冈萨雷斯感到不可思议。“那么,威克瑟姆为什么还要付给他工资?”,威克瑟姆好像要告诫冈萨雷斯不要那么大惊小怪。他盯着冈萨雷斯说道:“孩子,我要给你些忠告,忘掉你刚才看到的。我能够决定你的晋升或让你待在原地不动。”听到这些话,冈萨雷斯低声说了几句,然后就很快离开了。

这件事发生在昨天。冈萨雷斯曾试图知道其他职员是否也注意到类似威克瑟姆这种人和他做的那些事。结果他一无所获。从理论上讲,冈萨雷斯不该向威克瑟姆说什么,他该向沙伦·奥得哈姆汇报。但是,冈萨雷斯对他并不是很了解。如果他的做法证明是错误的,那后果会怎样呢?他并不能确定其他分析师或会计师会好到哪儿去。

“我该怎么办呢?这才是真正的问题。” 他叹息道。

 

 

案例分析个人观点:

首先,这是个复杂的问题。道德问题,涉及到个人道德底线的不同。谁也无法为冈萨雷斯做一个正确的决策。

如果能与冈萨雷斯免谈,我将通过GROW教练模型,了解冈萨雷斯的决策目的、现状、可能的决策可能,通过了解其回答内容的自身偏向,引导其做出符合自身职业道德标准的决策。

如果,我是冈萨雷斯,那么自己的道德标准在哪里?那只能Assume了(实际工作中,尽量别Assume – ASS U and ME。 你不是我,所有的换位思考,都是在操蛋你和我),在假设中进行GROW分析:

G 决策目的
不再陷入此职业道德标准的漩涡

R 现状分析:
案例中涉及到三个人: 托尼·冈萨雷斯,一个Too Young Too Simple的新员工。 约翰·威克瑟姆, 一个肯定违背了基础职业道德的高级会计师;沙伦·奥得哈姆,一个勤奋的主管。
之于个人,冈萨雷斯在这家公司状态并不怎么样,首先需要反思的是自己。由于冈萨雷斯的个人沟通问题,与大家缺少沟通。冈萨雷斯之所以描述的案例详情,也于其沟通问题相匹配:企业内缺少沟通和信任。冈萨雷斯需要突破现状反思,是公司缺乏沟通,还是自己缺乏沟通。
之于他人,威克瑟姆,确实存在违背职业道德的行为,对于会计这一个严肃的岗位来讲,这个行为是不可被原谅的。但难以定夺的一点,是冈萨雷斯是否该向上级告发此事;但有一点,是肯定的可以去做的,冈萨雷斯不希望陷入这样的违背职业道德事情中去。
之于团队,很难确定,是否整个团队都有这样的情况,也无法确定,威克瑟姆的行为是个人过错,还是团队授权。

O & W 可能采取的行为及行为
1. 离开威克瑟姆,去其他的高级会计师那进行工作;
2. 找威克瑟姆认真的聊一次。一来问问实情,希望威克瑟姆能够停止此事;二来是希望他能写个推荐信,使行为1更为顺利。
3. 向主管了解一下公司的企业文化以及主管的道德底线,通过侧面的方式,了解主管是否容忍甚至授权此类事情发生;如果确认主管也认同此事,则提出辞职报告;如何向主管进行对话,这个技巧和方式需要学习,应该再立一个GROW模型进行分析。
4. 关于最严肃的问题:是否告发威克瑟姆。需要根据以上的行为结果进行判断。最有可能会采用的方式是向主管发出匿名函,请求对全司的会计进行复核,但并不会指名威克瑟姆有罪。

最后,再深入的聊一下道德底线:在明知道同事违背职业道德的情况下,是否应该揭发他。

先分析一下直接揭发后果:

  • 可能1:公司完全不知情后,严查此事,高级会计师威克瑟姆被开除,甚至进入监狱;
  • 可能2:公司原本就怀疑,但没有找到导火索,所以按兵不动。冈萨雷斯的揭发开启了此严查;
  • 可能3:公司知情,且默许。解法事件发生后,大家陷入尴尬,最终威克瑟姆被打50大板,冈萨雷斯被炒鱿鱼。
  • 可能4:。。。

从个人利己主义来看,不论哪种可能,唯一不可能的是,冈萨雷斯都不可能是受益者。特别是在部分国家,企业会存在或部分存在一些非常规手段进行”合理“避税或其他隐藏的会计规则。如果冈萨雷斯处于这样的国家之内,他的举报行为,很有可能会断送他自己的职业规划,因为他向上司举报了他的同僚,将来,可能向公众媒体举报他所负责的公司。
所以,揭发这一决策,对于冈萨雷斯而言,是最差的决策。

所以,明哲的选择是不揭发,但自身职业道德要求又觉得有必要提醒上级,那只能采用匿名的方式,提醒公司,目前的会计机制有问题,需要通过制度改革,来弥补这个历史错误。

一个靠谱的GIT分支模型(GIT Flow)

作者:Vincent Driessen

原文连接: http://nvie.com/posts/a-successful-git-branching-model/

译者:罗春晖

译文连接:http://www.luochunhui.com/blog/a-successful-git-branching-model/

译者注:这是一套靠谱的git分支指导。充分的适配于团队的日常开发、新功能开发、紧急bug修复,通过该模型可建立一套行之有效的上线发布流程。本模型后来作为 GIT Flow 的标准被推行。

 

In this post I present the development model that I’ve introduced for some of my projects (both at work and private) about a year ago, and which has turned out to be very successful. I’ve been meaning to write about it for a while now, but I’ve never really found the time to do so thoroughly, until now. I won’t talk about any of the projects’ details, merely about the branching strategy and release management.

本文我将介绍近一年内,在我项目中(包括公司项目和个人项目)应用的开发模型。实践证明,这个模型发挥了非常良好的效果,相当靠谱。很早之前我就想写点东西,但直到今天才抽出时间。本文不涉及任何的项目细节,仅仅讨论分支策略和发布管理方法。

It focuses around Git as the tool for the versioning of all of our source code.

本文版本管理工具使用GIT。

Why git?

为什么使用GIT

For a thorough discussion on the pros and cons of Git compared to centralized source code control systems, see the web. There are plenty of flame wars going on there. As a developer, I prefer Git above all other tools around today. Git really changed the way developers think of merging and branching. From the classic CVS/Subversion world I came from, merging/branching has always been considered a bit scary (“beware of merge conflicts, they bite you!”) and something you only do every once in a while.

经过一些讨论和对比,我们最终选用GIT作为我们的版本管理工具,详情参考文章: GitSvnComparison 。GIT有非常多的亮点,作为一个开发人员,GIT是我最喜欢的版本管理工具,没有之一。 GIT改变了开发人员对代码分支和合并的思维方式。在经典的CVS/SVN的世界中,分支和合并被认为是危险的(小心合并冲突,他真的会咬你!),我们经常不得不考虑在很长一段时间,绝对必要时才去进行一次合并操作。

But with Git, these actions are extremely cheap and simple, and they are considered one of the core parts of your daily workflow, really. For example, in CVS/Subversion books, branching and merging is first discussed in the later chapters (for advanced users), while in every Git book, it’s already covered in chapter 3 (basics).

但在GIT中,分支和合并工作是很方便和简单的,他们可以作为日常工作的一部分。比方来说,在CVS/SVN的书籍中,分支合并的讨论一般会作为高级教程,放在全书的后面章节。但在GIT的书籍中,分支介绍则作为基础章节中进行提前介绍。

As a consequence of its simplicity and repetitive nature, branching and merging are no longer something to be afraid of. Version control tools are supposed to assist in branching/merging more than anything else.

因为GIT作为新的版本管理工具,给我们提供了相当完善的分支和合并支持,妈妈再也不用担心我们在分支和合并时难受了。

Enough about the tools, let’s head onto the development model. The model that I’m going to present here is essentially no more than a set of procedures that every team member has to follow in order to come to a managed software development process.

介绍完工具,接下来我们将定义一个开发模型。通过这个模型,我们约定所有的开发人员的操作规范,建立对应的处理流程,使得软件的开发过程更易于管理。

Decentralized but centralized

去中心化和中心化

The repository setup that we use and that works well with this branching model, is that with a central “truth” repo. Note that this repo is only considered to be the central one (since Git is a DVCS, there is no such thing as a central repo at a technical level). We will refer to this repo as origin, since this name is familiar to all Git users.

在这个模型中,我们需要一个唯一的中心仓库(从技术角度来看,GIT并没有中心仓库概念)。我们将其命名为origin,这个名字GIT用户都比较熟悉。

 

Each developer pulls and pushes to origin. But besides the centralized push-pull relationships, each developer may also pull changes from other peers to form sub teams. For example, this might be useful to work together with two or more developers on a big new feature, before pushing the work in progress to origin prematurely. In the figure above, there are subteams of Alice and Bob, Alice and David, and Clair and David.

每一个开发人员都从origin中拉取和推送代码。在中心仓库之外,模型也允许开发人员相互之间进行代码的拉取和推送,形成一个小项目组,允许两个或两个以上的人员共同开发一个新功能。在新功能完成之前,这个小项目组不必将代码提交给origin。在上图中,Alice和Bob,Alice和David,Clair和David分别组成了三个小项目组。

Technically, this means nothing more than that Alice has defined a Git remote, named bob, pointing to Bob’s repository, and vice versa.

技术方面,Alice需要定一个GIT远程仓库,命名为Bob,并连接至Bob的本地代码仓库。其他的子小组成员也是一样。

The main branches

主要分支

At the core, the development model is greatly inspired by existing models out there. The central repo holds two main branches with an infinite lifetime:

  • master
  • develop

核心模型与传统的GIT简单开发模型相似。在中心仓库中,包含了两个主要的分支,这些分支在项目生命周期中一直存在:

  • master 主分支
  • develop 开发分支

The master branch at origin should be familiar to every Git user. Parallel to the master branch, another branch exists called develop.

master主分支是GIT用户的常用名称。与master主分支同时存在的分支,称之为develop开发分支。

We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.

origin/master作为主要分支之一,是因为这个分支上的最新代码总是代表着生产环境的发布版本。

We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.

origin/develop作为另一个主要分支,是因为这个分支上的最新代码代表着开发人员为下一个发布版本提交的最新代码。有时我们也将其称之为『集成分支』。它一般可用于自动集成工具发布『每日构建』。

When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number. How this is done in detail will be discussed further on.

当源代码在develop分支中被开发完成,并准备发布时,所有的提交变更都应该被合并至master分支,并使用tag工具标记一个版本号。详细的操作方法我们稍后会继续讨论。

Therefore, each time when changes are merged back into master, this is a new production release by definition. We tend to be very strict at this, so that theoretically, we could use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master.

也就是说,在master上出现新的代码提交和合并时,就代表一个新的生产发布需求产生了。在实际中工作中,我们可以建立一个git钩子脚本,自动检测master分支的变更。当master上有新的提交时,我们就自动编译代码并发布至生产环境。

Supporting branches

辅助分支

Next to the main branches master and develop, our development model uses a variety of supporting branches to aid parallel development between team members, ease tracking of features, prepare for production releases and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.

讨论完主分支和开发分支后,接下来我们介绍一些辅助分支。他们将用于支持团队成员的并行开发,包括新功能开发、生产发布准备,生产环境的问题修复等。和主要分支不同,辅助分支一般只在需要时被建立,生命周期结束后即被释放删除。

The different types of branches we may use are:

  • Feature branches
  • Release branches
  • Hotfix branches

我们使用的辅助分支有如下几类:

  • 新功能分支
  • 发布分支
  • BUG修复分支

Each of these branches have a specific purpose and are bound to strict rules as to which branches may be their originating branch and which branches must be their merge targets. We will walk through them in a minute.

每一种分支都有特殊的用途,对分支的创建和合并操作进行了严格定义。它们只能从指定的来源分支建立,然后必须合并至另一指定的目标分支。我们很快会讨论细节。

By no means are these branches “special” from a technical perspective. The branch types are categorized by how we use them. They are of course plain old Git branches.

技术上将,这些分支和普通的GIT分支没什么两样。我们只是按照他们的用途进行分类。

Feature branches

新功能分支(别名:特性分支)

May branch off from:
develop
Must merge back into:
develop
Branch naming convention:
anything except master, develop, release-*, or hotfix-*
分支来源:
develop
分支合并目标:
develop
分支命名规范:
任何名字,但不要使用 master, develop, release-* 或 hotfix-*

Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).

新功能分支(有时也称之为特性分支)被用于即将开发的或更长期的功能开发。新功能分支建立时,我们可能还无法准确预知它的能完成时间。新功能分支在该功能开发过程中存在,当开发完毕后,被合并至develop分支,完成其生命周期。

Feature branches typically exist in developer repos only, not in origin.

新功能分支一般在开发人员的仓库中存在,不需要在origin中被创建。

Creating a feature branch

创建一个新功能分支

When starting work on a new feature, branch off from the develop branch.

从develop分支中创建新功能分支:

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

Incorporating a finished feature on develop

将新功能分支合并至develop分支

Finished features may be merged into the develop branch to definitely add them to the upcoming release:

当新功能完成时,我们将其合并至develop分支,准备下一次发布。

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature. Compare:

--no-ff 标记强制创建一个新的提交,禁止合并操作使用『快速前进(fast-forward)』方式进行。这样可以避免在合并时丢失了新功能分支脚力和消亡过程。标记功能的比较图示如下:

In the latter case, it is impossible to see from the Git history which of the commit objects together have implemented a feature—you would have to manually read all the log messages. Reverting a whole feature (i.e. a group of commits), is a true headache in the latter situation, whereas it is easily done if the--no-ff flag was used.

在右侧图中,新功能分支中的所有提交,都被嵌入到了develop分支中,除了认真阅读提交的日志信息,没法把他们分离出来。当我们试图回顾这个新功能分支中做了哪些改动时,将是个很麻烦的事情。但我们加上--no-ff标记,则可以很容易的解决这种麻烦。

Yes, it will create a few more (empty) commit objects, but the gain is much bigger than the cost.

当然,这会导致新创建了一个空的提交。但它带来的好处,远大于这一点点消耗。

Release branches

发布分支

May branch off from:
develop
Must merge back into:
develop and master
Branch naming convention:
release-*
分支来源:
develop
分支合并目标:
develop 和 master
分支命名规范:
release-*

Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s. Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the develop branch is cleared to receive features for the next big release.

发布分支用于新版本发布前的准备工作。它允许我们在发布前,做最后一点点改动,包括少量BUG的修改、元数据(如版本信息、编译参数等)的修改等。当所有工作完成后,develop分支再将这些修改全部合并回来,开始下一个版本的开发工作。

The key moment to branch off a new release branch from develop is when develop (almost) reflects the desired state of the new release. At least all features that are targeted for the release-to-be-built must be merged in to develop at this point in time. All features targeted at future releases may not—they must wait until after the release branch is branched off.

发布分支仅在我们决定发布新版本时进行创建,从develop分支中拉取并标记新版本的发布状态信息。此时所有准备上线的功能代码,都必须先合并至develop分支。针对未来的功能改动不得提交至此分支,它们必须等待下一个发布计划进行提交。

It is exactly at the start of a release branch that the upcoming release gets assigned a version number—not any earlier. Up until that moment, the develop branch reflected changes for the “next release”, but it is unclear whether that “next release” will eventually become 0.3 or 1.0, until the release branch is started. That decision is made on the start of the release branch and is carried out by the project’s rules on version number bumping.

发布分支决定了新版本及新版本号的开始。在此之前,develop分支并不决定下一个版本的版本号,不清楚下一个版本应该是『0.3』还是『1.0』,直到下一个发布分支建立时,才能知道。版本号命名交由将由项目版本管理计划决定。

Creating a release branch

创建一个发布分支

Release branches are created from the develop branch. For example, say version 1.1.5 is the current production release and we have a big release coming up. The state of develop is ready for the “next release” and we have decided that this will become version 1.2 (rather than 1.1.6 or 2.0). So we branch off and give the release branch a name reflecting the new version number:

发布分支从develop分支创建。举例来说,假设我们现在已经发布的版本为1.1.5 。开发人员已经基本完成了代码开发工作。经过评估,我们认为这次改动较大,决定将其作为版本1.2(不是1.1.6,也不是2.0)进行发布,然后创建这个新的发布分支:

$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

After creating a new branch and switching to it, we bump the version number. Here, bump-version.sh is a fictional shell script that changes some files in the working copy to reflect the new version. (This can of course be a manual change—the point being that some files change.) Then, the bumped version number is committed.

创建新的发布分支并切换后,我们声明了版本号。在bump-version.sh脚本中,我们修改了一些工作文件,以便新版本生效(也可以手工修改)。然后提交掉这些代码。

This new branch may exist there for a while, until the release may be rolled out definitely. During that time, bug fixes may be applied in this branch (rather than on the develop branch). Adding large new features here is strictly prohibited. They must be merged into develop, and therefore, wait for the next big release.

这个分支将存在一段时间,直到这次发布完成。在此期间,可能发生一些bug修复(这些修改不在develop分支进行)。 不允许提交大功能的改进代码,它们必须被合并提交到develop,然后等待下一个发布工作。

Finishing a release branch

完成发布分支

When the state of the release branch is ready to become a real release, some actions need to be carried out. First, the release branch is merged into master (since every commit on master is a new release by definition, remember). Next, that commit on master must be tagged for easy future reference to this historical version. Finally, the changes made on the release branch need to be merged back into develop, so that future releases also contain these bug fixes.

当一个发布分支已经准备好分布时,需要可以进行如下操作。首先,该发布分支需要被合并至master分支(注意,所有master分支的提交都代表一个新的发布工作);然后,对master增加一个tag,以便未来对历史进行跟踪;最后,所有发布分支上的提交都需要合并回develop分支,确保下一个发布工作中包括了所有的bug修复。

The first two steps in Git:

前两项工作的GIT操作如下:

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

The release is now done, and tagged for future reference.

通过这些操作,一次发布工作已经完成,并标记了tag,以供未来参考之用。

Edit: You might as well want to use the -s or -u <key> flags to sign your tag cryptographically.

提醒:在tag操作中,你可能需要增加-s-u <key> 参数,用来对tag代表的代码进行签名,防止纂改。

To keep the changes made in the release branch, we need to merge those back into develop, though. In Git:

为确保下一个发布工作中包括了本次发布分支中所有的变更,我们还需要在develop中进行合并工作,git命令行如下:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

This step may well lead to a merge conflict (probably even, since we have changed the version number). If so, fix it and commit.

本操作可能会导致一些冲突(可能仅仅是版本号冲突)。如果发生了,就修复并且再次提交。

Now we are really done and the release branch may be removed, since we don’t need it anymore:

现在我们已经完成了发布分支的全部工作,我们可以删除它了:

$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).

Hotfix branches

紧急修复分支

May branch off from:
master
Must merge back into:
develop and master
Branch naming convention:
hotfix-*
分支来源:
master
分支合并目标:
develop 和 master
分支命名规范:
hotfix-*

Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version.

紧急修复分支和发布分支相似,但它并不是计划中的工作。它应用于生产环境中出现的紧急bug修复。紧急修复分支基于线上运行的tag号签出,并以此为基础进行修改。

The essence is that work of team members (on the develop branch) can continue, while another person is preparing a quick production fix.

这样,此处修复可以不影响当前的开发工作(在develop分支中),专门抽取一个人力来快速的修复生产环境的问题。

Creating the hotfix branch

创建一个紧急修复分支

Hotfix branches are created from the master branch. For example, say version 1.2 is the current production release running live and causing troubles due to a severe bug. But changes on develop are yet unstable. We may then branch off a hotfix branch and start fixing the problem:

紧急修复分支基于master创建。比方来说,现在生产环境运行的是1.2版本,不幸的是,它发生了一个严重的bug。与此同时,我们的开发工作正在进行中,还没有准备下一次发布。我们需要创建一个紧急修复分支,来解决现在生产服务器上发生的问题:

$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

Don’t forget to bump the version number after branching off!

建立分支时,别忘了声明新的版本号。

Then, fix the bug and commit the fix in one or more separate commits.

然后,并通过一两次代码提交工作,来完成bug的修复工作。

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)

Finishing a hotfix branch

完成紧急修复分支

When finished, the bugfix needs to be merged back into master, but also needs to be merged back into develop, in order to safeguard that the bugfix is included in the next release as well. This is completely similar to how release branches are finished.

当修复工作完成后,代码重新合并至master进行发布。同时将其合并至develop分支,已确保在下一次发布工作中正常的包含了本次修复。合并工作于发布分支操作类似。

First, update master and tag the release.

首先切换到master分支,合并,然后标记tag。

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1

Edit: You might as well want to use the -s or -u <key> flags to sign your tag cryptographically.

提醒:在tag操作中,你可能需要增加-s-u <key> 参数,用来对tag代表的代码进行签名,防止纂改。

Next, include the bugfix in develop, too:

然后,在develop中合并本次分支:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

The one exception to the rule here is that, when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop. Back-merging the bugfix into the release branch will eventually result in the bugfix being merged into develop too, when the release branch is finished. (If work in develop immediately requires this bugfix and cannot wait for the release branch to be finished, you may safely merge the bugfix into develop now already as well.)

这里需要做一个特别说明,如果此时已经创建了一个发布分支,正准备下一次上线工作,则紧急修复分支应该被合并至该发布分支,而不是develop分支。紧急修复的代码将在发布分支完成时,经由发布分支合并至develop分支中(如果develop分支也需要立即使用这个紧急修复的代码,则也可以将紧急修复分支同时合并在develop中)。

Finally, remove the temporary branch:

最后,移除这个临时的修复分支。

$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).

Summary

总结

While there is nothing really shocking new to this branching model, the “big picture” figure that this post began with has turned out to be tremendously useful in our projects. It forms an elegant mental model that is easy to comprehend and allows team members to develop a shared understanding of the branching and releasing processes.

这个分支模型没什么可惧怕的,在文章最开始的概览图中已经包含了全部有用的信息。相信你能够很容易的理解,并指导团队建立一个可协作的、易于使用和理解的分支和发布流程。

A high-quality PDF version of the figure is provided here. Go ahead and hang it on the wall for quick reference at any time.

PDF的阅读版本附在文后,便于你可以翻阅查看。

下载PDF版本(英文版)

 

 

Jenkins基础

Jenkins是一个自动化引擎,开发者通过工作流、使用插件构建一套适用于自己或企业的构建生态系统,完成持续化集成、自动测试、持续发布的工作。

工作流(pipeline)

Jenkins工作流是V2版本中推出的全新概念,使用Groovy编写。Groovy语法可以参考网址:Groovy syntax。如果你会编写Groovy是好的,但并不是绝对必须的。如果你有一些其他的语言编程经验,那么翻阅一下Groovy Syntax,参考现有的groovy说明,就能很快建立一个工作流。

工作流主要包括阶段(stage)、工作节点(node)、 工作步骤(step)概念。下一章我们会重点介绍。

节点(slave)

Jenkins的编译任务执行,都在节点中进行。Jenkins默认会在本机建立一个工作节点,小型团队可直接使用。但为了编译效率、权限管理,我将节点分为三类进行建设:

编译节点:根据编译的环境需求进行建立,如JDK,C,Android,Mac等。

临时节点:用于自动化用例测试、代码质量检查等代码质量处理工作。

发布节点:根据运营环境的访问策略,建立测试、准生产、生产节点。通过Jenkins的stash工具,将编译结果传输到发布节点,在由发布节点运行Ansible指令完成发布

插件(plugin)

Jenkins提供的了非常优秀的插件,常实用的插件包括

  1. 工作流,工作流是以插件的的方式加载到Jenkins中的,包括核心库和众多的工具库;
  2. SCM类,用于git,subversion的代码迁出,github插件提供对gtihub的访问权限;
  3. 权限管理:一般使用Role Strategy。对用户分角色、分项目进行精细化管理;
  4. 编译工具类,包括Maven、Ant、Gradle、xcode等

视图(View)

Jenkins根据工作流,通过可视化的方式将其展示出来,便于更好的监控和管理。

贴图

 

Steve工具介绍

Steve

建立了一个Bash脚本,用于启停进程。启停前后,均会对进程关联进程进行检查,确保进程被完全关闭,也确保进程被正确启动。 对于顽固进程特别有效! 功能:

  • 服务安全启动
  • 服务安全关闭
  • 监控服务状态
  • 自动重启服务。 当服务意外蹦了的时候,自动重启之
  • 以及Supervisord提供的管理服务的WEB工具

更多介绍和使用说明,参考 Wiki

安装

本脚本为纯Bash, 尽量较少运维依赖。 Git clone后即可使用。 服务启动依赖于Supervisor。 Supervisord是用Python实现的一款非常实用的进程管理工具,类似于monit。 Supervisord会能将你的程序转化为Daemon服务。

Supervisord 安装

supervisord可使用Linux系统原生的包管理工具安装,也可以使用easy_install, pip进行安装。 详细参考 http://supervisord.org/installing.html 简单介绍一下centos easy_install的方法:

 yum install python-setuptools
 easy_install -U supervisor
 echo_supervisord_conf > /etc/supervisord.conf
 supervisord

Supervisor 配置

在/etc/supervisord.conf中增加行。

[include]
files = /etc/supervisor.d/*.ini

建立/etc/supervisor.d/目录,以servicename.ini命名,建立需要管理的多项任务。 示例任务见 examples 下文件。 配置文件修改和任务新增后,别忘了重启supervisor服务。通过命令可查看各任务状态:supervisorctl status

Steve 配置

[hello]
###set the port here. You have to check the port manually.
use_port=10888
###set the pname here. I will check the processname which contains this.
use_pname=hello.jar
###sleep N second for next checking
sleep_time=2
### How many times need to check
retry_time=5
### use kill in N times checking
forcekill=1
### use kill -9 in N times checking
forcekill9=3
#stdlog=/data/jfpal_workspace/architect/samples/logs/
#JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home
#supervisor_name=hello
### type may be jar, tomcat, weblogic
type=jar
### file is no useful
file=/data/jfpal_workspace/architect/samples/hello.jar

配置为键值对,以=分割。 以#,[开头的配置行被直接忽略, 没有=号的也被忽略。 =号两边不要放空格, 行首行尾不要放空格。

  • supervisor_name (option) 如果没有填写,则和service名称相同。
  • use_port (option) 进程使用端口。 进程启停时,将检查端口占用情况。
  • use_pname (option) 进程名。 进程启停时,将通过ps进行检查。 应该选用能显示能唯一代表进程的名字,如文件名.jar等。 不要使用java等进程名,以防误判误伤。
  • sleep_time (option) Default: 5。检查后等待sleep_time秒后,进行下一次检查。
  • retry_time (option) Default: 5。检查失败后的重试次数
  • forcekill (option) 在第N次检查后,如果服务仍未停止,则使用kill -TERM杀掉进程。 检查包括port, pname检查。 N从0开始
  • forcekill9 (option) 在第N次检查后,如果服务仍未停止,则使用kill -KILLkill -9))杀掉进程。 检查包括port, pname检查。 N从0开始。 如果forcekill, forcekill9无此选项,或大约retry_time, 则不会使用kill灭进程。 forcekill9 数字应该大于 forcekill

Steve使用

下载到steve.sh脚本后,在同级目录下建立config文件夹,并建立配置文件。

./steve.sh -k restart -s tomcat

参数说明:

  • -s Server name 服务名称。将读取文件夹下对应的配置文件,执行steve
  • -k Action. start, stop, restart, debug 操作明。 对服务进行启动、停止、重启、或显示测试信息
  • -h|-? Show this message 帮助
  • -V Steve Version 显示Steve版本
  • -v Verbose 显示调试信息
  • -f Force run 强制运行,即使在检查中发生错误。 尽量别用。

Steve Processes

STOP

            +---------------+
            |               |
+Stop+------>   Check Port  |
            |               |
            +--------+------+
                     |                     +---------------------+
                     |                     |                     |
                     |                     |                     |
           +---------v--------+            |                     +<-------------------------------------+
           |                  |            |                     |                                      |
           |  Check PID file  |            |                     |                                      |
           |                  |            |                     |                                      |
           +---------+--------+            |                     |                                      |
                     |                     |             +-------v-------+     +---------------------+  |
                     |                     |             |               |     |                     |  |
                     |           +---------+----------+  |   CheckPort   o-----+  kill +Signal       |  |
          +----------v-------+   |                    |  |               |     |         When Needed |  |
          |                  |   |    Stop Service    |  +--------+------+     +-----+---+-----------+  |
          |  Check Process   |   |                    |           |                  |   |              |
          |       Name       |   +--------^-----------+           |                  |   |              |
          +--------+---------+            |                       |                  |   |              |
                   |                      |             +---------v--------+         |   |              |
                   |                      |             |                  |         |   |              |
                   |                      |             |  Check PID file  o---------+   |              |
                   |                      |             |                  |             |              |
                   |                      |             +---------+--------+             |              |
                   |                      |                       |                      |              |
                   +----------------------+                       |                      |              |
                                                                  |                      |              |
                                                       +----------v-------+              |              |
                                                       |                  |              |              |
                                                       |  Check Process   o--------------+              |
                                                       |       file       |                             |
                                                       +----------+-------+                             |
                                                                  |          Retry when                 |
                                                                  |          check failed               |
                                                                  +-------------------------------------+
                                                                  |
                                                                  |
                                                       +----------v------------+
                                                       |                       |
                                                       |      Stop Result      |
                                                       |                       |
                                                       +-----------------------+

START

             +---------------+
             |               |
-Start------->   CheckPort   |
             |               |
             +--------+------+
                      |                     +----------- ----------+
                      |                     |                      |
                      |                     |                      |
            +---------v--------+            |                      | <----------------+
            |                  |            |                      |                  |
            |  Check PID file  |            |                      |                  |
            |                  |            |                      |                  |
            +---------+--------+            |                      |                  |
                      |                     |              +-------v-------+          |
                      |                     |              |               |          |
                      |           +---------+----------+   |   CheckPort   |          |
           +----------v-------+   |                    |   |               |          |
           |                  |   |                    |   +--------+------+          |
           |  Check Process   |   |   Start Ser^ice    |            |                 |
           |    file          |   |                    |            |                 |
           +--------+---------+   +--------+-----------+            |                 |
                    |                      ^              +---------v--------+        |
                    |                      |              |                  |        |
                    |                      |              |  Check PID file  |        |
                    |                      |              |                  |        |
                    |                      |              +---------+--------+        |
                    |                      |                        |                 |
                    +----------------------+                        |                 |
                    |                                               |                 |
                    |                                    +----------v-------+         |
          +---------v---------------------+              |                  |         |
          |                               |              |  Check Process   |         |
          |         Exit                  |              |    file          |         |
          |   When the process is running |              +----------+-------+         |
          |                               |                         |                 |
          +-------------------------------+                         |   Retry when    |
                                                                    |  check failed   |
                                                                    +-----------------+
                                                                    |
                                                         +----------v------------+
                                                         |                       |
                                                         |                       |
                                                         |     Show  Result      |
                                                         |                       |
                                                         +-----------------------+

RESTART

STOP && Start

源码

源码代码库: https://github.com/gikoluo/Steve