软件公司组织架构（软件公司运维团队需要怎样的组织架构）

本文目录

• 软件公司运维团队需要怎样的组织架构
• 架构类型以及软件架构逻辑详解
• 一个小公司的组织结构有哪些
• 软件公司的测试部门有哪些常见的组织
• IT公司或着软件开发公司都有些什么部门

软件公司运维团队需要怎样的组织架构

重要的考虑因素是服务数量和服务形态。服务数量，确定不同的“团队”是部门，还是小组，或者仅仅是不同的岗位？设计运维的组织架构，实际上是设计服务提供方式。可以用三个步骤来思考：1）需要考虑提供什么服务；2）如何提供服务；3）服务有多复杂，是否需要不同的团队来完成？也就是：1）首先，需要考虑服务的有多复杂？也就是服务目录。辅导用户使用？帮助进行系统配置？修改系统缺陷？需要进行系统升级？2）其次，根据服务目录，可以设计需要如何提供服务。例如？远程解答，现场服务，现场修改？远程修改？3）最后，服务有多复杂？需要怎样的团队架构？如果只是进行解答，那么只是服务台即可，如果系统有比较深入的问题需要解答，那么需要有二线技术团队；如果需要现场服务，那么需要设立现场服务团队，如果系统非常复杂，个人无法掌握整个系统，哪么需要针对不同的子系统设立不同的技术服务团队。如果需要进行系统进行修改，哪么就要加上开发团队。另外，还需要考虑维护与开发和实施的接口。

架构类型以及软件架构逻辑详解

架构类型：分布式、SOA架构、单体式。

分布式架构

分布式应用架构中，相互独立，代码独立开发，独立部署，通过API接口互相通信。通讯协议一般使用HTTP，数据格式是JSON(是一种轻量级的数据交换格式)，应用集成方式比较简化。

优点: 应用内部高内聚，独立开发、测试和部署，应用之间松耦合，业务边界清晰，业务依赖明确，支持大项目并行开发。

缺点: API接口需求变化，应用就需要重新部署，通信可靠性和数据的封装性相对于进程内调用比较差。

SOA架构

SOA也是分布式应用架构一种。

SOA架构提供配套的服务治理，包括服务注册、服务路由、服务授权、服务降级、服务监控等等。

SOA架构既体现业务的拆分，又体现业务的整合，更多地从业务整体上考虑系统拆分。

优点：以服务层为主，聚焦核心业务，同时以提供整个系统共享，服务作为独立的应用，独立部署，接口清晰，很容易做自动化测试和部署，服务是无状态的，很容易做水平扩展；通过容器虚拟化技术，实现故障隔离和资源高效利用。

缺点：系统依赖复杂，给开发/测试/部署带来不便，分布式数据一致性和分布式事务支持困难，一般通过最终一致性简化解决。

单体式应用

系统只有一个应用、打包成一个应用；部署在一台机器；在一个DB里存储数据.

单体式应用采用分层架构，一般为表示层、业务层、数据访问层、DB层，表示层负责用户体验，业务层负责业务逻辑，数据访问层负责DB层的数据存取

优点：开发、编译、调试一站式、一个应用程序包含所有功能点，容易测试和部署

缺点：系统逐渐庞大时，代码复杂度高，难以维护，应用扩展水平低，业务和模块职责区分不清晰。

软件架构

一、 微服务架构

微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级。

每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。

微服务架构分成三种实现模式。

RESTful API 模式 ：服务通过 API 提供，云服务就属于这一类

RESTful 应用模式 ：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部

集中消息模式 ：采用消息代理（message broker），可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群

优点

扩展性好，各个服务之间低耦合

容易部署，软件从单一可部署单元，被拆成了多个服务，每个服务都是可部署单元

容易开发，每个组件都可以进行持续集成式的开发，可以做到实时部署，不间断地升级

易于测试，可以单独测试每一个服务

缺点

由于强调互相独立和低耦合，服务可能会拆分得很细。这导致系统依赖大量的微服务，变得很凌乱和笨重，性能也会不佳。

一旦服务之间需要通信（即一个服务要用到另一个服务），整个架构就会变得复杂。典型的例子就是一些通用的 Utility 类，一种解决方案是把它们拷贝到每一个服务中去，用冗余换取架构的简单性。

分布式的本质使得这种架构很难实现原子性操作，交易回滚会比较困难。

二、 事件驱动架构

事件（event）是状态发生变化时，软件发出的通知。

事件驱动架构（event-driven architecture）就是通过事件进行通信的软件架构。它分成四个部分。

事件队列（event queue）：接收事件的入口。

分发器（event mediator）：将不同的事件分发到不同的业务逻辑单元。

事件通道（event channel）：分发器与处理器之间的联系渠道。

事件处理器（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作

对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。

优点

分布式的异步架构，事件处理器之间高度解耦，软件的扩展性好；适用性广，各种类型的项目都可以用；性能较好，因为事件的异步本质，软件不易产生堵塞；事件处理器可以独立地加载和卸载，容易部署

缺点

涉及异步编程（要考虑远程通信、失去响应等情况），开发相对复杂难以支持原子性操作，因为事件通过会涉及多个处理器，很难回滚分布式和异步特性导致这个架构较难测试。

三、分层架构。

分层架构（layered architecture）是最常见的软件架构，也是事实上的标准架构。如果你不知道要用什么架构，那就用它。

这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口通信。

虽然没有明确约定，软件一定要分成多少层，但是四层的结构最常见。

表现层（presentation）：用户界面，负责视觉和用户互动。

业务层（business）：实现业务逻辑。

持久层（persistence）：提供数据，SQL 语句就放在这一层。

数据库（database） ：保存数据。

有的软件在逻辑层和持久层之间，加了一个服务层（service），提供不同业务逻辑需要的一些通用接口。

用户的请求将依次通过这四层的处理，不能跳过其中任何一层。

优点

1、结构简单，容易理解和开发。

2、不同技能的程序员可以分工，负责不同的层，天然适合大多数软件公司的组织架构

3、每一层都可以独立测试，其他层的接口通过模拟解决

缺点

1、一旦环境变化，需要代码调整或增加功能时，通常比较麻烦和费时

2、部署比较麻烦，即使只修改一个小地方，往往需要整个软件重新部署，不容易做持续发布

软件升级时，可能需要整个服务暂停

3、扩展性差。用户请求大量增加时，必须依次扩展每一层，由于每一层内部是耦合的，扩展会很困难。

五、 微核架构。

微核架构（microkernel architecture）又称为"插件架构"（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。

内核（core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。

优点

1、良好的功能延伸性（extensibility），需要什么功能，开发一个插件即可

2、功能之间是隔离的，插件可以独立的加载和卸载，使得它比较容易部署，

3、可定制性高，适应不同的开发需要

4、可以渐进式地开发，逐步增加功能

缺点

1、扩展性（scalability）差，内核通常是一个独立单元，不容易做成分布式

2、开发难度相对较高，因为涉及到插件与内核的通信，以及内部的插件登记机制。

五、 云架构。

云结构（cloud architecture）主要解决扩展性和并发的问题，是最容易扩展的架构。

它的高扩展性，主要原因是没使用中央数据库，而是把数据都复制到内存中，变成可复制的内存数据单元。然后，业务处理能力封装成一个个处理单元（prcessing unit）。访问量增加，就新建处理单元；访问量减少，就关闭处理单元。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里，最好要进行数据持久化。

这个模式主要分成两部分：处理单元（processing unit）和虚拟中间件（virtualized middleware）。

处理单元：实现业务逻辑

虚拟中间件：负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。

一个小公司的组织结构有哪些

公司应该有以下组织机构：
董事长，总经理，副经理，财务总经理，财务部，包括：会计，结算，出纳，记账，销售部包括：经理，主管，业务员，推广，市场策划，人力资源部：人事主管，经理，采购部，采购经理，采购员，文员，计划物流部，包括司机，搬运，仓管员，记账员，还有综合管理部，后勤部。
管理幅度是指一个人能直接高效地领导下属人数的限度，或称管理面的宽度。如一家企业总共有100人，公司总经理下面直接管理8个部门经理，则该总经理的管理幅度为8人。管理幅度的意义在于如果没有这个限度，一个人不能直接和有效地领导指挥成百上千的人，那么所有的管理职能均集中于老板身上，但老板一个人受精力、体力、时间和知识的限制，被管理的人数太多，面太宽，既管不好，也管不了。
管理层次就是在职权等级链上所设置的管理职位的级数。比如说一个企业，从上到下，有总经理、总监、部门经理、主管、职员，则管理层次共有五层。
管理幅度和管理层次是两个相对的概念。管理幅度大，则管理层次少；管理幅度小，则管理层次多。
一般而言，在没有系统、管理成熟度低的时候，一个人只能管理6-8个人，即管理幅度只有6-8个人；只有管理成熟度上升了，才能管理足够多甚至无限大的人数。
企业需结合纵向职能分工、组织效率的要求、组织不同部分的特点来确定。

（1）职能组织型：

该结构呈金字塔形，高层管理者位于金字塔的顶部，中层和底层管理者则沿着塔身向下分布。公司的经营活动按照设计、生产、营销和财务等职能划分成部门；一个项目可以作为公司中某个职能部门的一部分，这个部门应该是对项目的实施最有帮助或最有可能使项目成功的部门，例如开发一个新产品项目可以被安排在技术部门的下面，直接由技术部门经理负责。

（2） 矩阵组织型：

现代大型项目中应用最广泛的新型组织形式，它是职能组织型和项目组织型的结合，将职能组织型的纵向优势和项目组织型的横向优势有效结合起来。一个矩阵组织型由垂直的职能部门和水平的不同项目组结合而成一个矩阵，把集权和分权结合起来，从而加强了各职能部门同各项目之间的协作关系。

（3） 项目组织型：

在这种组织形式中，每个项目就如同一个微型公司那样运作，项目组的成员来自不同的部门，完成每个项目所需的资源完全分配给这个项目，专门为该项目服务。这种组织在大型软件开发中应用较多。

软件公司的测试部门有哪些常见的组织

测试总监-对应-开发总监
-测试经理-对应-开发经理
-测试组长-对应开发组长
-各级别测试人员（普通测试工程师）
每个级别的人的工作内容有所不同
有的企业里面还有测试架构师，测试设计师这样的职位。其中测试架构师和测试总监或者测试经理是平级的，测试设计师一般和测试组长是评级的，但是他们对于人员管理没有权限，管理的是项目本身。不过这类的职位一般在国内不多见。
还有，有些企业会把QA和QC分离，就是普通的测试部门（QC）和质量管理部（QA），质量管理部是在软件项目开始的时候和进行中进行规则管理和规划的人员。都需要知道类似于CMMi之类的东西。督促测试或者开发在流程上的一些强化定义，并且确保整个过程中的流程上的质量。
QA和QC糅合的企业也很多。两者的工作都有。只是看更加注重什么。
测试根据测试的角度可以氛围很多种。有些企业可以细化（规模大的）比如ST，UAT分成不同的部门。黑盒测试，白盒测试，灰盒测试是不同的team负责，自动化测试和手工测试等等。看公司定位，客户需求以及项目特点。

IT公司或着软件开发公司都有些什么部门

开发部：根据市场需求进行产品开发
技术部：进行技术这块的开发，前台和后台的管理
网销部：进行网上销售产品，推广产品
市场部（销售部）：跑市场，进行市场销售，面对面的销售。
财务部：记录公司的收入和公司的支出
行政部：负责公司的办公用品，体力方面的活
人事部：负责招聘人员，负责人事考核、考查工作。建立人事档案资料库，规范人才培 人事部公务员面试培养、考查选拔工作程序，组织定期或不定期的人事考核、选拔工作等等。