Best Practices for data center monitoring and server room monitoring

1. Rack Level Monitoring
Based on a recent Gartner study, the annual cost of a Wintel rack averages around $70,000 USD per year. This excludes the business cost of a rack. Risking losing business continuity or your infrastructure due to environmental issues is not an option. What are the environmental threats at a rack level?A mistake often made is to only rely on monitoring the conditions at a room level and not at a rack level. The American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) recommends no less than 6 temperature sensors per rack in order to safeguard the equipment (top, middle, bottom at front & back of rack). When a heat issue arises, air conditioning units will initially try to compensate the problem. This means that with room level temperature monitoring, the issue will only be detected when the running air conditioning units are no longer capable of compensating the heat problem. It may be too late then.We recommend monitoring temperature per rack at a minimum of 3 points: at the bottom front of the rack to verify the temperature of the cold air arriving to the rack (combined with airflow monitoring); at the top front of the rack to verify if all cold air gets to the top of the rack; and finally one at the top back of the rack which is typically the hottest point of the rack. Intake temperature should be between 18°-27°C / 64°-80°F. Outtake temperature should typically be not more than 20°C / 35°F of the intake temperature.

What is the impact of temperature on your systems? High end systems have auto shutdown capabilities to safeguard themselves against failures when temperature is too high. However before this happens systems will experience computation errors at a CPU level resulting in application errors. Then system cooling (fan) will be stressed reducing equipment life time expectance (and as such their availability and your business continuity).

   2. Ambient room monitoring
Ambient room monitoring is the environmental monitoring of the room for its humidity and temperature levels. Temperature and humidity sensors are typically deployed in:

  • potential “hot zones” inside the server room or data center
  • near air conditioning units to detect failure of such systems.When multiple air conditioning systems are available in a room, then a failure of one system will initially be compensated by the others before it may lead to a total failure of the cooling system due to overload. As a result temperature / airflow sensors are recommended near each unit to get early failure detection.Humidity in server rooms should be between 40% and 60% rH. Too dry will result in the build up of static electricity on the systems. Too humid and corrosion will start slowly damaging your equipment resulting in permanent equipment failures.

    When using cold corridors inside the data center, then ambient temperature outside the corridor may be at higher levels. Temperatures of 37°C / 99°F are not uncommon in such setups. This allows to significantly reduce the energy cost. However this also means that temperature monitoring is of utmost importance as a failing air conditioning unit will have a way faster impact on the systems lifetime and availability (fans stress, CPU overheating, …) and running a room at higher temperatures may also affect non rack mounted equipment.

    When using hot corridors it is important to monitor temperature across the room to ensure that sufficient cold air gets to each rack. In this case however one can also rely on rack based temperature sensors in addition of temperature and humidity sensors close to each air conditioning unit.

    3. Water & Flooding Monitoring

    Water leakage is a less known threat for server rooms & data centers. The fact that most data centers and server rooms have raised floors makes the risk even bigger as water seeks the lowest point.

    Two type of sensors for water leakage can be commonly found: spot and water snake cable based. Spot sensors will trigger an alert when water touches the unit. Water rope or water snake cable sensors use a conductive cable whereby contact at any point on the cable will trigger an alert. The latter type is recommended over the first one due to its higher range and higher accuracy.

    If using a raised floor, then one should consider putting the sensor under the raised floor as water seeks the lowest point.

    The four main sources of water in a server room are:

  • leaking air conditioning systems: a water sensor should be placed under each AC unit
  • water leaks in floors or roof above the data center & server room: water sensors should be put around the perimeter of the room at around 50cm/3ft from the outer walls
  • leaks of water pipes running through server rooms: a water sensor should be placed under the raised floors
  • traditional flooding: same as second point for water leaks from roof or above floors applies                                                                                                                                                                                                                                               4. Sensors DeploymentAll sensors connect to our Sensorgateway (base unit). A base unit supports up to 2 wired sensors, or up to 8 with the optional sensor hub.
    Application Location Setting SKU Sensor Package
    Rack Level Monitoring
    Sensors to monitor intake temperature Front – Bottom of rack for room or floor cooling, top of rack for top cooling 18-27°C / 64-80°F 182668 Temperature probes*
    Sensors to monitor outtake temperature Back – Top of rack (hot air climbs) less than 20°C / 35°F difference from inlet temperature (typically <40°C / 105°F) 182668 Temperature probes*
    Ambient Monitoring
    Temperature & humidity monitoring in server room small server rooms: center of the room data centers: potential hot zones – furthest away from airco units Temperature depends on type of room setup
    Humidity: 40-60% rH
    306166 Temperature & Humidity Sensor Probe*
    Airconditioning Monitoring
    Early detection of failing air conditioning units next to airco units Temperature depends on setting of airco
    Humidity: 40-60% rH
    306166 Temperature & Humidity Sensor Probe*
    Water Leaks / Flooding
    Detecting water leaks coming from outside of room Around outside walls of server room / data center and under raised floor
    best is to keep a 30-50cm / 10-20″ from outer wall
    180004 Flooding Sensor Probe* with 6m/20ft water sensitive cable
    Detecting water leaks from air conditioning units Under each air conditioning unit 180004 Flooding Sensor Probe* with 6m/20ft water sensitive cable

    * External probes need to be connected to a Sensorgateway (SKU 311323) in order to operate. One Sensorgateway has a built-in temperature probe and can support up to 2 external probes.

Source from:



Service Portfolio vs Service Catalog: 5 Reasons You Should Know the Differences

At first glance, the service portfolio and service catalog almost seem like the same thing. After all, both contain details of IT services. However, there are important differences when you’re talking about service portfolio vs. service catalog.

two hammers
To the casual observer, these may look similar, but use the wrong one for the job, and the differences become obvious.

service portfolio is an overarching document used in the management of the life cycles of all services: including those no longer offered, those currently offered, and those in the pipeline. The service portfolio is more of a living historical document of service-related activities.

service catalog, on the other hand, details the currently-active IT services and may include information on those that will be deployed soon. The service catalog is an “outward facing” document for your end users.

To use an analogy, suppose you’re an architect. Your portfolio contains examples of work you have completed for your clients, work representative of what you’re doing now, and information about where you want to take your expertise in the future. If you as an architect were to create the equivalent of the “service catalog,” it would contain information about exact services you provide, how the services are performed, how long they take to complete, and how much you charge.

There are several reasons you should understand the service portfolio vs service catalog differences. Here are 5 of them.

1. To Remain Consistent with ITIL Framework

This is a matter of good corporate IT hygiene. When you bring in a new IT service manager, collaborate with another company on an IT initiative, bring in a consultant, or take on the task of creating a service catalog and portfolio, knowing the difference between the service portfolio and the service catalog keeps everyone on the same page and makes communication easier.

2. To Prioritize Your Efforts

There are varying opinions on which should come first: the service catalog or the service portfolio. The choice may depend on many factors, including how well-documented past IT services were and what your resources allow. The service catalog is a more focused document, and many people think that this is where your initial efforts should be focused, followed by use of the information in the service catalog as a springboard to creating a service portfolio. The “right” answer about which to tackle first depends on your particular organization’s priorities and resources.

3. To Know Where to Place Your “Marketing” Efforts

The service portfolio is usually an internal document that the IT help desk and management use to gain a historical overview of IT services, assess what worked and what didn’t, and try to lay out long-term plans. It doesn’t “market” services, per se. Your service catalog, however, being an outward-facing document primarily directed at end users, really is like a catalog: here is a service you may be interested in, what this service does, how it’s done, and how long you can expect it to take. It should be written with less “IT-speak” so that end-users understand and appreciate it.

4. To View ITSM Both Long Term and Short Term

Service portfolio vs. service catalog is also about long-term versus short-term. The service portfolio gives the long view and helps you determine how to play the long game, with fewer specifics. Technology changes so rapidly that trying to nail down specific future services using just the information in your service portfolio may be an exercise in futility. Your service catalog, on the other hand, is about here and now, and the near future.

5. To Prepare End Users for Upcoming Changes

Just as your local game store gives you release dates so you’ll know when to expect an anticipated product, your service catalog can tell end users: “Our social help desk app is scheduled to launch September 1” (or whatever). Service catalog users generally have less interest in long-term plans with unknown effects (like when your new data center is expected to be complete), and are more interested in finding out things like, “When does the help desk integration with Salesforce Chatter go live?” or “When will the IT help desk start using remote desktop support so I don’t have to wait for someone to show up or walk me through a fix?”

The service portfolio and service catalog are both important, living documents that make planning and delivery of IT services better. Samanage, a leading cloud IT service management software provider, gives you the tools you need for creating and managing your IT service catalog and developing a service portfolio that can help your organization map out where it’s been and where it needs to go.

source from:

Maximize Your Investment with SolarWinds Solutions

Maximize Your Investment with SolarWinds Solutions
Live Webcast: 2 February 2016 |  9:30 AM (SGT) / 12:30 PM (AEDT)

As we start the New Year, it is a great time to look at the latest features added to SolarWinds® solutions, and how these features support the growth of your network and business. The webcast includes updates on SolarWinds network management, application and server management, virtualization management, and storage management.Learn how the latest added features will help you save you time, mitigate risk and maximize your SolarWinds investments. During this interactive webcast, you will learn about the most common customer requests as we share tips for getting the most from your product implementations, including:
  • ⇒ Network Performance Monitor
  • ⇒ Network Configuration Manager
  • ⇒ Server & Application Monitor
  • ⇒ Virtualization Manager
  • ⇒ Storage Resource Monitor

Schedule conflict? Sign up anyway and get a copy of the presentation after the webcast.

Register now to save your spot!

The 4 Ps of ITIL Service Management

The IT Service Management life cycle has 5 stages – strategy, design, transition, operation and improvement. During service design, the 4 Ps need to be considered – People, Process, Products and Partners. An effective IT service strategy needs to acknowledge the importance of all of these.

This is just one small part of what is covered on our ITIL Foundation course, which teaches you real life applications of the ITIL framework as well as the knowledge needed to pass the ITIL Foundation exam.

4 Ps of ITIL



The first ‘people’ to consider are the people that work in the IT services. Service managers need to ensure the following:

  • That their staff have the skills to match the roles
  • They have sufficient staff to support the service
  • That the roles and responsibility of the staff are fit for purpose
  • That culture and communication within the service is appropriate
  • That ongoing training can be provided to fill skills gaps
  • That the IT service fits with the organisational structure and that the right relationships are in place

The next people to be considered are the customers of the service. These are the recipients of the service, and the SLA is agreed with them. The customer is usually another manager within the organisation, or a business owner. For more information, have a look at our blog post on key customer conversations.

The service userare very important. The service must be designed to make the user experience as effective as possible – the users usually feed back to the customer.


The definition of a process is “A set of coordinated activities combining and implementing resources and capabilities in order to produce an outcome, which directly or indirectly, creates value for a customer or stakeholder.”

An effective process must be measurable; have specific results that are identifiable and accountable; must deliver to customers and stakeholders (meet their expectations); and must be able to respond to specific events.

In ITIL, each process will have a Process Owner, whose role includes the following:

  • definition of process strategy and standards
  • assisting with process design
  • keeping process documentation updated
  • ensuring the process is efficient and effective
  • ensuring the right resources and training is provided
  • providing input to Service Improvement Programmes
There will also be a Process Manager, whose role includes the following:
  • accountability for the the operational management of a process
  • working with the Process Owner to plan
  • appointing people to their roles
  • managing resources assigned to processes
  • monitoring and reporting the performance of the process
  • identifying potential improvements
Finally, there will be a Process Practitioners who:
  • carries out process activities
  • creates and updates records to show activities and duties carried out

Products (technology)

An IT service depends on the following technology/products:

  • Its own technology to run efficiently to support others
  • Monitoring tools
  • Automation
  • Support tools
  • Communication tools

Partners (suppliers)

Suppliers have a big impact on IT services – the staff depend on these third parties to deliver the goods or services needed to run the IT service. It’s important for appropriate partnership agreements to be formed, i.e. contracts and service level agreements.

The 4 Ps of ITIL

By managing the 4 Ps, the ITIL framework makes sure that all aspects of an effective IT service strategy are covered. All of the 4 Ps must be aligned to corporate goals to ensure the best, most appropriate, service is delivered.

Read more:

ITSM vs. ITIL: What’s the Difference?

If you’re not sure whether you need ITSM or ITIL®, then I’m pretty sure you’re asking the wrong question. It’s not an “either/or” decision. IT service management (ITSM) is what you do to manage the services you deliver to your customers, even if you don’t actually use that term. ITIL is a best practice framework for ITSM, and you should think about adopting some ideas from ITIL to help you work more effectively.

ITSM or ITIL: What's the Difference?

Here’s what you need to know about ITSM and ITIL, and how each can contribute to the success of your IT organization.

What’s the Difference?
Let’s start with a quick overview of what these terms stand for:

  • ITSM is an acronym for IT service management. It simply means how you manage the information systems that deliver value to your customers. Even if you’ve never heard the term ITSM, if you’re running IT systems, then you are doing ITSM. ITSM could include activities like planning and managing changes so they don’t cause disruption to the business, fixing things when they go wrong, or managing a budget to ensure you can pay the bills when they arrive. People who use the term ITSM tend to think of IT as a means of delivering valuable services to their customers, rather than as a way to manage technology—but even if you have a completely technical focus, your work still needs to be managed, and that’s what we call ITSM.
  • ITIL is the name of the world’s most widely recognized framework for ITSM. ITIL is a registered trademark of AXELOS, which owns a range of best practice solutions and their corresponding publications and exams. ITIL has been adopted by many organizations, and there are millions of certified ITIL practitioners worldwide.

Benefits of ITIL
It is likely that some—probably many—of the ITIL best practices would prove beneficial to your organization. Organizations that adopt ITIL often find that they:

  • Improve the alignment of IT to their business, providing services that better meet the needs of their customers.
  • Improve the quality of the IT services they deliver by understanding the required levels of availability, security, capacity, and continuity, and then planning solutions that are able to deliver these.
  • Lower the cost of delivering IT by reducing wasted effort and focusing on getting things right the first time.

You don’t have to adopt ITIL to manage your IT services effectively and efficiently, but it can certainly help. Some organizations simply create their own set of processes for running IT, and this can work. But it’s hard to develop something original that matches the years of experience that have gone into the development of the ITIL best practice framework that has now been adopted by many thousands of organizations.

Adopt and Adapt to Fit Your Needs
IT organizations that make use of ITIL decide for themselves which aspects to adopt. Many IT organizations choose to adopt only the operational processes, such as incident management and change management. On their own, these do provide some value, of course, but they are only a small part of the whole ITIL framework. However, you’ll get the best value from ITIL by taking a lifecycle approach to ITSM. This covers everything from your overall IT strategy through the design, transition, and operation of services; and it incorporates continual improvement into everything you do.

When your organization has made the decision to adopt a best practice framework, a smart strategy is to understand which approach will be a good fit for your organizational culture and to incorporate it into your own management system in a sympathetic way. I have worked with many organizations that start our relationship by telling me they tried ITIL a few years ago, but it didn’t deliver any value. When I investigate what happened, I usually discover they attempted to adopt a rigid set of processes, with no understanding of how they would fit within the culture of their organization. As a result, people would ignore the new processes—so the money spent on the project ended up being wasted. The right way to use ITIL is summarized in the phrase “adopt and adapt.” You only adopt the parts that you need, and you adapt the ideas to fit your environment rather than slavishly following the guidance.

Additional Frameworks to Explore
The smartest organizations tend to use other standards or best practice frameworks in combination with ITIL. This can be very effective as each approach brings something different to the mix. For example:

  • COBIT is a very good framework for governance, audit, and compliance. It is much stronger than ITIL in these areas, and the two work very well together.
  • Agile and DevOps help to ensure the IT organization quickly delivers new business functionality. They often conflict with ITIL because of cultural differences between the people who adopt them, but they can fit together very well if the organization understands the value provided by each.
  • Lean can be used to drive continual improvement and elimination of wasted effort. It is a great fit with ITIL continual improvement.

If you run IT services, you owe it to your customers to adopt ideas that will make you effective, efficient, and agile. So maybe it’s time you had another look at ITIL to see what it has to offer.

source from:

ITIL & Solarwinds – Web Help Desk

SolarWinds, a leading provider of powerful and affordable IT Management software, acquired Web Help Desk in July 2012, adding the company’s trusted Web-based IT Help Desk software to our product portfolio, further extending the range of problems we can help IT Professionals solve.

Since our founding in 1999, SolarWinds’ (NYSE: SWI) mission has been to provide purpose-built products that are designed to make IT professionals’ jobs easier. We offer value-driven products and tools that solve a broad range of IT management challenges — whether those challenges are related to networks, servers, applications, storage or virtualization.

We distinguish ourselves by refusing to accept the status quo established by most other enterprise software vendors. Face it: the vast majority of IT management tools today are difficult to use, expensive, and really do not address the realities of today’s real-world IT management challenges. We do not think enterprise software has to be as complicated as it’s made out to be.

At SolarWinds, we are fanatical about putting our users first in everything we do. We strive every day to deliver powerful functionality that is easy to use with one of the fastest and longest lasting ROIs in the market.

Our approach is to deliver “unexpected simplicity” and redefine the expectations IT Pros have of enterprise software.

Our web-based IT service management and IT asset management software solutions empower organizations to efficiently automate and simplify their increasingly complex service environments. Widely admired for our dedicated focus on ease of use, aesthetics and affordability for our customers, our IT solutions deliver fast time-to-value, increased control, and reduced risk for a broad range of sectors, including educational institutions, governmental agencies, small businesses, and large enterprises.

Web Help Desk makes both first time and enterprise-level automation simple and reduces complexity for help desk management, service desk management, IT service management, IT asset management, inventory and desktop management, compliance management, and knowledge management.

Quản lý sự thay đổi trong ITIL – Change Management

Một trong những khó khăn lớn nhất cho doanh nghiệp là phải đối mặt với sự phức tạp của hệ thống IT do các thành tố tạo thành của nó không chỉ do một tổ chức đơn lẻ cung cấp mà là sự kết hợp của rất nhiều tổ chức.

 1. Tổng quan

Hệ thống IT của doanh nghiệp không ngừng phải được cải tiến, bổ sung, sửa đổi hoặc thậm chí phải loại bỏ. Một trong những khó khăn lớn nhất cho doanh nghiệp là phải đối mặt với sự phức tạp của hệ thống IT do các thành tố tạo thành của nó không chỉ do một tổ chức đơn lẻ cung cấp mà là sự kết hợp của rất nhiều tổ chức (thậm chí đôi khi còn mất mơ hồ và không được xác định rõ).

Bên cạnh đó, các phát minh và sáng chế trong lĩnh vực IT (hiện đang có tốc độ phát triển nhanh nhất trong tất cả các linh vực) cũng không ngừng thâm nhập vào hệ thống IT của doanh nghiệp – nơi mà yêu cầu phải có sự nhất quán và đồng bộ rất cao mới có thể vận hành và khai thác hiệu quả.

Do vậy, yêu cầu đặt ra cho doanh nghiệp là phải kiểm soát và theo dõi được tất cả các biến động của hệ thống IT cũng như những tác động đến hệ thống này mới có cơ may sống sót và phát triển trong môi trường cạnh tranh khốc liệt đang diễn ra.

2. Quản lý sự thay đổi

Quản lý thay đổi thật sự cần thiết nhằm đảm bảo rằng tất cả các thay đổi đối với hệ thống IT không ảnh hưởng tiêu cực đến các cấp độ dịch vụ. Các thay đổi phải được thực hiện theo các phương pháp và thủ tục đã chuẩn hóa một cách hiệu quả và nhanh chóng để giảm tối đa sự ảnh hưởng.

Các từ viết tắt và định nghĩa

Từ viết tắt Diễn giải
RFC (Request for Change) Một yêu cầu thay đổi được đề xuất của bất kỳ sự thêm, bỏ hoặc thay đổi đối với bất kỳ CI nào trong hệ thống IT.
RFC LOG (Request for Change Log) Mỗi yêu cầu thay đổi đều được cấp một mã số để có thể theo dõi và tham chiếu. Thông tin được ghi nhận trong nhật ký sẽ được sử dụng trong các cuộc họp xem xét các yêu cầu thay đổi và cho các yêu cầu tương tự trong tương lai.
FSC (Forward Schedule of Change) Thông tin được ghi nhận trong quản lý thay đổi về bất kỳ sự xuất hiện nào của thay đổi được gửi đến. Thông tin này rất quan trọng đối với PSA (Projected Service Availability).
CAB (Change Advisory Board) Một tổ chức bao gồm từ Phụ trách Quản lý thay đổi đến các nhân viên hỗ trợ và các chuyên gia tư vấn SME (Subject Matter Experts). Các thành viên của tổ chức này sẽ gặp gỡ định kỳ để phê duyệt và đánh giá các yêu cầu thay đổi. Nhân sự tham gia trong các cuộc họp có thể thay đổi tùy thuộc vào loại RFC.
CAB/EC (Change Advisory Board Executive Committee) Các thành viên được chọn từ tổ chức CAB để làm đầu mối liên hệ để đánh giá và phê duyệt các thay đổi trong các tình huống nghiêm trọng hoặc khẩn cấp nằm ngoài kế hoạch xem xét định kỳ.
Board (Senior Management Board Level) Quản lý cao cấp ra các quyết định chiến lược có thể dẫn đến sự thay đổi quan trọng đối với hệ thống IT. Sau khi đã được phê duyệt, các thay đổi này sẽ được chuyển cho CAB để được cấp phép và lên lịch thực hiện.
CM (Change Manager) Có các nhiệm vụ sau đây:-          Quản lý toàn bộ các RFC-          Tổ chức và chủ trì các cuộc họp của CAB, quyết định những ai tham dự đối với mỗi cuộc họp.-          Cung cấp các FSC thông qua Service Desk
PSA (Projected Service Availability) PSA là bản báo cáo và là kết quả của FSC. Nó chứa các chi tiết của sự thay đổi liên quan đến SLA (Service Level Agreement).Thông tin này cũng được sử dụng để phát triển các SLA mới.

Sự thay đổi là gì?

Sự thay đổi là một hành động thay đổi trạng thái của một CI trong hệ thống IT.

Hoạt động Quản lý thay đổi

Chu kỳ sống của một thay đổi

Changelife-quan ly su thay doi

Sàng lọc


Phụ trách thay đổi phải đánh giá tất cả RFC được đề xuất. Việc đánh giá dựa trên nội dung của tài liệu RFC; do vậy cần phải xem xét thông tin về RFC đã chuyển đến có đầy đủ thông tin hay không? Thông tin đầy đủ sẽ đảm bảo sự thay đổi có thể được thực hiện nhưng hạn chế phá vỡ các cấp độ dịch vụ.


Nội dung Yêu cầu thay đổi (RFC)

  • Mã số RFC
  • Ai sẽ bị ảnh hưởng bởi thay đổi (Who)
  • Mô tả (What, Where)
  • Đánh giá sự ảnh hưởng
  • Thời gian cần thiết để thay đổi (When)
  • Lý do thay đổi (Why)
  • Thông tin người liên hệ (Who)
  • Kế hoạch phục hồi


Phụ trách thay đổi phải trả lời các câu hỏi sau đây khi xem xét, đánh giá và phê duyệt các thay đổi:

  • Đã có loại yêu cầu thay đổi nào cùng loại đã được chấp nhận trước đây chưa? Phụ trách thay đổi sẽ xem kỹ lại nếu một RFC như vậy đã có.
  • Có đề xuất nào bị từ chối không? Vì sao?
  • RFC đó có được thực hiện thành công không? Vì sao thành công hoặc vì sao không? Phụ trách thay đổi cần phải hiểu được mục tiêu của thay đổi được đề nghị.

Điều này chỉ có thể được thực hiện bằng cách lập sẵn một tài liệu RFC mẫu để sử dụng cho tất cả các bộ phận IT. Nếu RFC hoàn tất và được phụ trách thay đổi chấp nhận, nó sẽ được chuyển qua cho CAB. Tuy nhiên, sự chấp nhận ở đây không tương đương với việc cấp phép/phê chuẩn (authorization). Nếu thay đổi là đủ nhỏ thì phụ trách thay đổi có thể tự cấp phép. Nếu phụ trách cấp phép đối với một thay đổi và nghĩ rằng điều đó là cần thiết thì ban CAB sẽ được thông báo thay đổi đã được cấp phép.

Xác định độ ưu tiên và phân lớp

Một RFC sau khi đã được phụ trách thay đổi chấp nhận sẽ được phân loại và xác định mức độ ưu tiên. Các công ty đều thiết lập riêng cho mình một “phạm vi mô hình thay đổi” để phân lớp. Phân lớp sẽ dựa vào mức độ ảnh hưởng và mức độ khẩn cấp của yêu cầu thay đổi. Các thay đổi có thể được phân lớp trong phạm vi có thể do công ty xác định. Ví dụ, các yêu cầu thay đổi dựa vào mức độ ảnh hưởng của vấn đề và sự khẩn cấp của giải pháp: Ngay lập tức, Cao, Trung bình, Thấp. Trong đó:

  • Ngay lập tức: Ảnh hưởng nghiêm trọng đến hệ thống hoặc đến nhiều người dùng. Các hành động cấp thời cần được thực hiện (CAB/EC)
  • Cao: Ảnh hưởng nghiêm trọng đến các chức năng kinh doanh và cần phải thiết lập ở độ ưu tiên cao.
  • Trung bình: Không có ảnh hưởng nghiêm trọng nhưng cần phải sửa chữa và hiệu chỉnh trước khi phát hành hoặc nâng cấp.
  • Thấp: Yêu cầu thay đổi là hợp lý nhưng không cấp thiết lắm.

 Cấp phép/Phê duyệt

Phụ trách thay đổi có thể cấp phép cho các thay đổi nhỏ nhưng phải thông báo cho bộ phận CAB là thay đổi đó đã được cấp phép.

  • Bộ phận CAB sẽ cấp phép cho các thay đổi mức độ vừa và quan trọng.
  • Senior Level (Board of Directors-Ban giám đốc) sẽ cấp phép cho các thay đổi lớn mang tính chiến lược. Sau khi được họ cấp phép, việc cấp phép này sẽ chuyển đến cho bộ phân CAB xem lại.

Nội dung cấp phép sẽ đánh giá mức độ ảnh hưởng của tất cả các yêu cầu thay đổi. Việc đánh giá sẽ dựa vào các tiêu chí sau đây:

  • Sự ảnh hưởng đến kinh doanh
  • Sự ảnh hưởng đến các mục tiêu của các SLA
  • Các dịch vụ khác
  • Sự ảnh hưởng nếu không thực hiện
  • Nguồn lực và chi phí (Thời gian và con người)
  • FSC và PSA hiện thời
  • Ảnh hưởng của sự thay đổi đối với sản phẩm/dịch vụ cuối
  • Duy trì hoạt động bảo trì các tài nguyên

Tổ chức thực hiện thay đổi

Từ đầu đến cuối của cả tiến trình tổ chức thực hiện thay đổi là duy trì cập nhật đến thời điểm hiện tại thông qua việc cập nhật vào nhật ký RFC. Phụ trách thay đổi chuyển tất cả các thông tin cập nhật vào nhật ký RFC.


Phụ trách thay đổi sẽ đảm bảo rằng các tài nguyên hợp lý đã được phân công để xây dựng thay đổi. Các thông tin này được nêu trong RFC và sẽ được ghi nhận bởi các cá nhân hoặc các nhóm.


Kiểm thử sẽ được tổ chức thực hiện bởi người yêu cầu sau khi việc xây dựng thay đổi hoàn tất. Các chỉ định kiểm thử cũng nên đưa vào trong tài liệu RFC. Những người xây dựng chỉ được tham gia kiểm thử đối với các thay đổi khẩn cấp nếu thời gian cho phép.


Sau khi kiểm thử hoàn tất và thỏa mãn được người yêu cầu thay đổi cũng như người xây dựng, phụ trách thay đổi sẽ tổ chức triển khai để đưa thay đổi vào hệ thống.

Xem xét sau triển khai

Sau khi các thay đổi đã được đưa vào hệ thống, phụ trách thay đổi sẽ tổ chức xem xét lại kết quả sau khi triển khai để biết được quy trình thay đổi hoạt động như thế nào đối với thay đổi đã được triển khai. Một số câu hỏi cần được giải đáp trong giai đoạn này là:

  • Điều gì đã dẫn đến cần phải thay đổi? Nếu sự thay đổi này là một kết quả từ một vấn đề nào đó thì việc quản lý vấn đề cần phải tham gia trong quá trình xem xét và đánh giá lại sau triển khai.
  • Làm như thế nào để tránh được các vấn đề đã dẫn đến sự thay đổi này?


Xử lý các thay đổi khẩn cấp

Sẽ không có nhiều thời gian để xử lý khi một thay đổi được coi là khẩn cấp. Phụ trách thay đổi-người phải đương đầu với loại thay đổi này- sẽ khởi động tiến trình được CAB/EC triệu tập để đánh giá sự thay đổi. CAB/EC sẽ gồm các thành viên được được lựa chọn từ CAB-những người có trách nhiệm hoặc được ủy quyền để ra các quyết định ở cấp độ cao. Các chỉ dẫn rõ ràng cùng với một tiến trình phối hợp cần thiết được thiết lập khi có thay đổi được coi là khẩn cấp. CAB/EC sẽ được triệu tập một khi được thông báo. Họ sẽ đánh giá thật nhanh tình huống, cấp phép và tổ chức thay đổi. Sau khi thay đổi đã được xây dựng và triển khai hoàn tất, CAB/EC sẽ tham gia vào trong quá trình xem xét lại sau khi triển khai thay đổi đó.

Đánh giá sự ảnh hưởng và nguồn lực

  • Sự ảnh hưởng của thay đổi đến kinh doanh
  • Cần thiết phải cân nhắc cẩn thận về thay đổi và các đơn vị kinh doanh bị ảnh hưởng bởi thay đổi
  • Sự ảnh hưởng đến các mục tiêu của các SLA
  • Sự ảnh hưởng đến các dịch vụ khác
  • Ảnh hưởng đến các dịch vụ khác không phải là IT
  • Sự ảnh hưởng nếu không thực hiện thay đổi
  • Nguồn lực và chi phí (Thời gian và con người)
  • FSC và PSA hiện thời
  • Duy trì hoạt động bảo trì của các tài nguyên

Một số vấn đề tiềm ẩn trong tiến trình Quản lý Thay đổi

  • Có sự thay đổi lớn về văn hóa IT
  • Nhận thức một cách quan liêu
  • Cố gắng đi tắt (không tuân thủ đầy đủ các yêu cầu)
  • Sự phục tùng tùy tiện của Nhà cung cấp hay đối tác trong các thỏa thuận
  • Song hành – Phụ trách thay đổi sẽ song hành cùng với tất cả các dịch vụ IT cần thiết cho kinh doanh dựa trên các thay đổi được chuyển đến. Phụ trách thay đổi cần phải hiểu rõ sự ảnh hưởng của bất kỳ thay đổi nào đến kinh doanh.
  • Hiệu quả được cải thiện cho cả người dùng lẫn nhân sự IT:
    • Người dùng: Các thay đổi có chất lượng tốt hơn với sự hỏng hóc ít hơn
    • Các nhân sự IT: Phụ trách thay đổi đảm bảo rằng các nhân sự IT hỗ trợ hợp lý tham gia xử lý các thay đổi sẽ dẫn đến kết quả sử dụng tài nguyên tốt hơn.
  • Rủi ro: Quản lý thay đổi đánh giá và chọn lọc tất cả các RFC nên rủi ro triển khai một thay đổi kém sẽ được giảm xuống.
  • Chất lượng: Các báo cáo liên quan đến thay đổi đều được ghi nhận sẽ cho phép nâng cao chất lượng khi thực hiện thay đổi. Quản lý thay đổi cần phải tạo các báo cáo cho tất cả các thay đổi,  thông tin bao gồm:
    • Mã số yêu cầu thay đổi
    • Phân loại
    • Kết quả (Thành công/Không thành công)

 Tags: đào tạo itil,