Don Jones. “Creating a unified IT monitoring system in your environment” Chapter 1. Managing your IT environment: four things you do wrong

From translator

Since I started monitoring, a lot of time has passed, and if at first the monitoring was a specific technical task, then over time its value (at least for me personally) moved up many steps and now stands in along with the basic tools for doing business, such as, for example, a corporate information system.

Having started spreading some of my articles and translations on the subject of monitoring IT infrastructure, I again had to come across a very narrow and technical understanding of this topic, which I had once had and therefore I once had the idea to present this systematically. I even started, slowly, to write an article on this topic, but intuitive things didn’t fit very well on paper - there was no forest behind the trees. Of course, we all have Google and the ability to spy on what other authors write, but it wasn’t there. Countless articles and blog posts were devoted to the technical aspects of perching another monitoring system on the next version of the operating system and the heroic overcoming of difficulties associated with this. Articles on monitoring methodology, principles for choosing metrics, there was very little proper construction of the process and linking it with the business, and they also described some particular cases of applying monitoring to solve a particular problem and nothing more. And then I accidentally fell into the hands of a very small book by Don Jones, “Creating a Unified IT Monitoring System in Your Environment (ENG)”.

This was what was needed - it described the philosophy, set out a number of concepts and listed some areas, following which, it is possible to ensure that the monitoring system works for IT and the organization as a whole, and from the details the overall picture finally began to take shape. I came to some ideas on my own, but I was glad that I found a lot of new things, which seemed interesting and worthy of discussion among specialists. And most surprisingly, this book was free.

Why did I decide to translate it? Of course, I have no doubt that 2/3 of the inhabitants on the habr read well and speak English, but we must think about those who do not know how to do this or he does not have the patience to master so many English letters. I personally prefer to read in Russian, especially when it’s not related to the terminology, which has a controversial translation into Russian (hello, PMBOK!), But is connected with vital and rather emotional topics. Translation is my personal initiative, I do not receive any material benefits from it and I see it as my only task to bring new knowledge to a wide range of readers, hoping that someone may be able to reflect on their daily problems and see that their solution exists. My only merit is the retelling in Russian words of thoughts expressed by the author. :)

In addition, I would really like to discuss the ideas and suggestions contained here. It is no secret that the difference in mentality, lifestyle, legal framework can give rise to its own specific problems that differ from those described by the author, and there are probably already tried and tested ways to deal with them, just a wide part of the IT people are not aware of this.

This book, first of all, will be useful to IT managers - heads of departments and services, IT monitoring project managers, chief and leading specialists, system administrators who are going to someday become managers and try to understand what their activities mean for the organization as a whole .

PS All emphasis in italics in the text is copyright, unless otherwise specified.
Content

Chapter 1. Managing your IT environment: four things that you do wrong.
Chapter 2. Eliminating management practices for individual sites in IT management.
Chapter 3. Connecting everything into a single IT management cycle.
Chapter 4. Monitoring: looking beyond the data center.
Chapter 5: Turning Problems into Solutions
Chapter 6: Unified Management with Examples

From the author. Introduction to Realtime Publishers

Over the course of seven years, Realtime has produced dozens of high-quality books destined to be distributed electronically; moreover, free of charge for you readers. We managed to make this publishing model workable through generous support and cooperation with our sponsors, who agreed to take on the burden of producing each book for the benefit of our readers.

Although we have always offered our publications to you completely free before, do not hesitate for a minute that quality means less to us than our main goal. The goal of my work is to make sure that our books are just as good, and in most cases even better than any printed book that costs you $ 40 or more. Our electronic publishing model has a number of significant advantages over printed books: you get chapters literally right after our authors write them (this is an aspect of the “real time” present in our model), and we can make changes to reflect them new trends in technology. I would also like to emphasize that our books are not advertising and not white papers. We are an independent publishing company, and an important aspect of my work is to provide a platform for our authors to be able to express their expert opinion without any restrictions and reservations. We maintain full editorial control over our publications, and I am proud that we have managed to create so many quality books in recent years.

I would like to invite you to visit our site nexus.realtimepublishers.com , especially if you received this book from a friend or colleague. We have a large number of other books on a wide variety of topics, and undoubtedly you will find something that you may be interested in - and it will not cost you anything. We hope that you will continue to visit Realtime for educational purposes in the future.

With pleasure,

Don Jones, editor of the series.

Chapter 1. Managing Your IT Environment: Four Things You Do Wrong

At the very beginning of the existence of the IT industry, the concept of “monitoring” meant a person who wandered in search of burnt out electronic lamps among the cabinets where the mainframe was located. Of course, this was not the right way to identify faulty vacuum devices that worked in slightly more difficult conditions than they were intended for this. Thus, monitoring, at that time, was an extremely reactive way of responding to problems.

At the same time, the help desk was the same guy answering phone calls, when one or another dozen “computer people” needed help in pushing cards into the reader, in tracking down burned out lamps, and so on. The concepts of tickets, knowledge bases, service level agreements (SLAs) have not yet been invented. IT management has since improved significantly, but unfortunately, not to the level that it could or should have been. Certainly, our work tools have become significantly more complex and mature, but the way we use these tools is our IT management processes, in some ways, they still remain at the level of reactive methods of replacing radio tubes.

Some of the concepts on which IT management practices are based in many organizations actually harm them, although logically, IT should support their work. The discussion in this chapter will focus on a few key topics that will smoothly move into subsequent chapters of the book. The goal is to change your thinking about how IT management should work, and in particular, monitoring; what value IT should bring to the organization, and how you should make a turn to better manage your IT environment.

IT management: how we got to this, and why we have what we have

At the beginning of the existence of IT, we dealt with relatively simple systems, even simplified, if we consider them through the prism of today's standards. The team of IT specialists often consisted of people who were able to solve any of the problems that arose, if only because the systems did not have such a large number of “moving parts” if we represented IT in the form of a car. The machine was complex in its own way and was able to do a variety of things, but at the same time it was completely understood by a single person.

As the IT car began to turn into a spaceship, we gradually required specialization. Personal systems have become so complex that we need experts with specific knowledge who are able to monitor, maintain and manage each system.

Messaging systems. Database. Infrastructure components. Directory Services

The vendors creating these systems, together with third-party manufacturers, have developed tools to help our experts monitor and manage each system. And it was there that everything went wrong, although at some point in time everything looked wonderful, and, in reality, there might have been no other way to carry out these tasks, but that was what led to the formation of their own domains (domain-specific silos) - each with its own individual tools, procedures and expertise - what has become the problem of “separate towers” ​​within many IT services.

And now we’ll quickly move to the present when our systems have become significantly more complex, with a huge number of connections and, moreover, they are increasingly located outside our own data centers. When a user encounters a problem, it’s obvious that they cannot tell us whichof our complex systems there is a problem. They just tell us what they see and how, in their opinion, this problem manifests itself, which may be the combined result of the interaction of several systems and their interdependencies. Our users see a holistic environment - “IT” in general, which is somewhat different from what we see from our back-end: databases, servers, directories, files, networks, and much more. As a result, we often spend a lot of time tracking the true cause of the problem, and, worse, we often don’t even see an impending incident, because the problem is present only when you look at the end result of the work of the whole environment, and not some of its separate parts. Users feel completely divorced from the process, and in addition, a help desk, which is sometimes useful and sometimes not, separates them from IT.

The way we built our IT services led us to very specific problems at the business level, and they became common concerns and sources of complaints around the world:

• IT has difficulty defining and matching a business SLA. “The mail server will work 99% of the time” - this SLA is not for business, it is a technical agreement. “E-mail will be seamlessly transmitted between external and internal users of the mail system 99% of the time” - this is a business-level SLA, but it is difficult to measure because this statement involves significantly more systems than a simple mail server (Actually it is extremely imprudent to subscribe to responsibility for systems that are outside the boundaries of the responsibility of the local IT service, let's hope that the author did not mean anything else - pr .
• IT has difficulty proactively predicting complex situations based on indicators of the overall “health” of IT systems, so IT services, for the most part, remain reactive in solving problems.
• When a problem happens, IT often spends too much time figuring out the cause of it in detail.
• The concepts of performance and “system health” used in IT are based on systems — database servers, directory service servers, network devices, and so on — and not on how users and the organization as a whole perceive the services provided by these systems.
• The IT service is working hard while adapting new technologies that can benefit businesses. It sounds strange, but the fact remains - the IT service is often the part of the organization that is most resistant to change, because change is usually the trigger of many troubles. Faulty systems do not help anyone, but the inability to quickly introduce changes to the structure of the company can also be a threat to the competence of the organization and its flexibility in the near future.
• The IT service is working very hard, adapting new technologies that significantly extend beyond the experience and competence of the team or are beyond physical accessibility, especially when it comes to the mass of outsourced offers, usually combined under the concept of “cloud computing”. These technologies and approaches are so different from what they used to be that IT does not feel confident in monitoring and managing new systems. Therefore, they resist the implementation of such decisions, fearing that their implementation will harm the organization.
• Even with state-of-the-art self-help systems at the service desk, users feel incredibly helpless and divorced from the situation when it comes to IT.

All of these business-level stumbling blocks are a direct result of how we manage IT. Our monitoring and IT management processes typically have four main problems. Of course, not every organization has them all at once, most at least have heard of them and are working hard to counter them. However, companies need to clearly understand that they have an idea of ​​all four problems, and if this is done, then almost immediately we can begin to address the business issues that we mentioned earlier.

Problem 1: You manage IT in separate areas (“towers”).

Figures 1.1, 1.2, and 1.3 illustrate one of the fundamental problems in IT monitoring and management today.


Figure 1.1: Measuring Windows OS performance in Windows Performance Monitor.


Figure 1.2: Measuring the performance of a DBMS server in SQL Server Performance.


Figure 1.3: Measuring processor load on the router

Numbers represent the performance / load status of various components of the IT system. Each of these images is created by a tool that is more or less specialized for tracking the results of a specific task. The software that is used to track the performance of a router, for example, is not able to reproduce a similar picture for a database server or even for a router located on another network.

This is such a general and fundamental problem that most IT experts do not even want to admit that this is a problem. The use of these separate, strictly specific tools is such an entrenched and natural practice in the work of IT that most of us simply cannot think of anything else. Nevertheless, we need to leave in the past the use of these specialized tools as the first line of defense when it comes to monitoring and resolving problems.

Why?

One of the main reasons is that these tools do not allow us to remain on the “one page”. When specific tools are involved, a logical and multidisciplinary discussion among IT experts fails. “I look at the DBMS server and its performance is more than 200 transactions per minute,” says one expert. "Well, that could be a problem because the router processes more than 10,000 packets per minute." Two specialists do not have a common language in which they could talk productively about productivity, because each of them is locked in their own “tower” —the deep technical aspects of the technologies with which they primarily work.

Field-specific toolkits also encourage the worst practices in all IT services, namely looking at systems in isolation. The DBMS administrator has no idea how the routers work, which is the good or bad performance of the mail server, or what you need to look at to make sure that the directory service infrastructure is working as expected. Therefore, the DBMS administrator puts on horse blinders and looks only at the database servers, but his servers do not work in a vacuum; other systems influence their work, just as they themselves influence the rest of the infrastructure. Everything works together , but we cannot see it., because we use too specialized tools. Basically, this means that we need new tools that will allow specialized tools designed to access individual “towers” ​​to work in a single team, moving the information that everyone needs into a common context. Without a doubt, specialized tools will always be in demand, but they will not be our first line of access to information.

Jerry works in a typical IT department at a mid-sized company. His specialty is the administration of Windows servers. His team has specialists in Web applications, MS SQL Server and Oracle, VMware vShpere, as well as network infrastructure. Some corporate applications are outsourced: CRM (customer relationship management) and mail.

Recently, an incident occurred that stopped sending customers email messages containing an electronic order confirmation. To solve the problem, they initially hired Jerry, on the assumption that the reason could be in the outsourced postal service. However, Jerry found out that the mail goes fine. He referred the problem to a web solutions specialist, who confirmed that the website itself was working fine, but that the mail he sent was wrapped somewhere. Jerry filled out a ticket at a mail hosting company, and she replied that their systems were working fine and that it would be nice to check the passwords that the client’s web servers use.

More than a day passed by correspondence with the hosting company and various experts, and the problem finally went down to the corporate firewall. Not so long ago, an upgrade to the new version was made, and it blocked outgoing mail traffic from the perimeter of the corporate network, exactly where the company's web-servers were located. They called a network specialist, he reconfigured the firewall and the problem was resolved.

This story accurately illustrates the essence of the problem: if we manage our teams of IT specialists as specific principalities, we significantly impede their ability to work together to solve problems. The fact that they need a specialized tool to do the work should not be an obstacle to the destruction of the boundaries of individual possessions and more effective joint work. This becomes especially important when some parts of the infrastructure are outsourced; hosting companies are sovereign “states” because they are not responsible for any other systems except the ones they provide. However, the dependence of our systems and processes on their systems means that our own team must be able to monitor and know what to do with them in case of malfunctions,as if these systems were right in our data center

Problem 2: There is no connection between your users, service desk and IT management.

Communications is a key component that makes any team work; and in this case, the “team” representing your organization is no exception. In the case of IT, we usually use systems for help desk organizations, implying that this is a reasonable way of communicating, but this is not always enough. Help desk systems, as a rule, are based on the concept of responding to a problem and subsequent management of the reaction, and by definition, they are practically not proactive .

For example, how do you inform your users that this system will have reduced performance or will be shut down for a certain period of time? Perhaps by email, which creates a couple more problems:

• An important message tends to get lost in the influx of emails that the user receives every day.
• Users who do not understand or do not receive the message have the habit of going through the help desk, which has no way to intervene in thought processes and in a non-contact way explain to them what the event was planned for, which users consider to be a “problem”.

Most IT teams are well aware of what is needed for successful communications throughout the organization, for example:

• Service Level Agreements (SLAs)
• Current SLA status - how they are being implemented.
• Planned outages and slowdowns
• Average response time of individual services
• Current issues that are in the works.

The problem with most IT teams is the exchange of information on these topics throughout the organization. Some companies rely on email, which, as I mentioned earlier, may be insufficient and not quite effective. Some offices use an internal website, such as the SharePoint portal, on which notes are published, but these sites do not have direct integration with the help desk, so an additional step is required to synchronize information on both systems, and users are required remember that you must periodically go to the portal.

Tom works as a sales manager for a mid-sized manufacturing company. Recently, the application that Tom used to track prospective customers and create new accounts began to respond very slowly and, by the end of the day, completely froze. Tom's initial reaction was to call the help desk of the company's IT services. The help desk technical specialist told Tom in a tired voice: “We are in the know, we are working on it,” and hung up. Tom has no information about when the system will work again and he was afraid to call back to the help desk and find out the state of affairs in more detail.

At the end of the day, the help desk recorded calls from almost every seller, each of whom called on their own initiative, wanting to understand what was happening. In the end, the help desk stopped registering calls, informing everyone who called, "the ticket is already open" and hanging up. Finally, one of the IT managers finally sent out an e-mail explaining that the server was out of order and the application would not work until the next morning. Tom would love to know this before; because he was going to call customers all day, but if this information that the application would not be available for so long had arrived in a timely manner, he would have done something else, or even taken a day off.

Management communications are as important as they are complex. Ensuring honest numbers in the levels of service, reaction time, lack of services and so on - all this is extremely important if management needs to make well-developed IT decisions, but reliable information is often not easy to get.

Problem 3: You measure both.

This problem, perhaps, is at the heart of any IT service - inaction in adapting technology to the needs of the business. The following example demonstrates just such a scenario.

Shelley works in accounting. Recently, while trying to close the general ledger, the accounting program began to work extremely slowly. She called the IT help desk to report a problem. The technician listened to her, and then said: “Right now on the server, everything is in order. I’ll open a ticket and ask someone to see what is being done there, but since the parameters of the service agreement by the response time are not violated, this will be a ticket with a low priority. "

Shelley continued to struggle with a slowly responding program. In the end, someone guessed to come and look at her desktop. She demonstrated that all other programs worked fine. She pointed out that other employees in her department experienced similar problems with this application.
A technician forced her to close all other applications and then restarted her computer, but everything remained as before. He shrugged, took a few notes on his smartphone and left.
The next morning, the application response time was better, but still far from normal. Shelley continued to call the help desk, trying to find out what was wrong with her application, but it looked like the IT service had given up trying to fix the problem, and even refused to admit that there was a problem.

Unfortunately, this kind of situation often happens in many organizations. This example accurately illustrates what happens when several problems happen simultaneously: IT does not work as a team, but as a group of disparate specialists, and each of these groups has its own understanding of the word “slow”. The main reason was that everyone was measuring something wrong and wrong . Figure 1.4 shows how a regular IT service sees a multicomponent, distributed application:


Figure 1.4 IT service view of a distributed application.

They see the components. Experts for each component measure their performance using technical metrics such as processor utilization, response time, etc. When one of the components is out of tolerance, one of the engineers begins to check it. Figure 1.5 shows how the user sees the same application.


Figure 1.5 User view of a distributed application.

The user does not see (very often - cannot see) the internal structure. There is an application for him, and either it answers in the expected way or not. It doesn’t matter to the user whether a particular component works with an “acceptable level of processor utilization” - he does not know thatit means. He cares if the application works; which creates a large gap between the perceptions of the user and the IT engineer, as shown in Fig. 1.6.


Fig. 1.6. Performance measurement by the user and IT engineer.

Users and the IT service measure different things. An IT-oriented SLA may indicate a specific response time to requests sent to the DBMS server, but this is of little use if the application, from the user's point of view, is “slow”. What's worse, if we start migrating services and components to the cloud, then we lose most of our ability to determine the performance of our components in the way we are used to doing in our data centers. Result? Neither side will be satisfied with the provisions of such an SLA.

All this needs to be changed. We need to learn how to measure things from a user's perspective. The performance of individual components is important, but only to the extent that it affects the overall performance felt at a particular workplace. We need to register such SLAs in which both the user and the IT service are located on the same page, then control the execution of these SLAs in the ways and tools that allow this to be done successfully. Some organizations report that they are transitioning, or have already switched to the work of IT on the basis of the provision of services - this, in a broad sense of the word, means that the company is looking for a way to implement the work of IT services in the form of a set of services for various departments of the organization and their users. However, in many cases, these service-oriented organizations are still focused on components and devices, which, generally speaking, is not at all a service-oriented approach. When your telephone exchange falls, you do not call the telephone company (possibly from your mobile phone) and do not start asking questions about switches and trunks - you ask when the usual buzzer will appear again in your handset. The internal structure does not matter to the user. The credit of your expectation is not based on how long the office of a particular telephone company will be inoperative, you ask yourself how long you can afford the lack of a good telephone connection. It is to this model that information technology services should move. When your telephone exchange falls, you do not call the telephone company (possibly from your mobile phone) and do not start asking questions about switches and trunks - you ask when the usual buzzer will appear again in your handset. The internal structure does not matter to the user. The credit of your expectation is not based on how long the office of a particular telephone company will be inoperative, you ask yourself how long you can afford the lack of a good telephone connection. It is to this model that information technology services should move. When your telephone exchange falls, you do not call the telephone company (possibly from your mobile phone) and do not start asking questions about switches and trunks - you ask when the usual buzzer will appear again in your handset. The internal structure does not matter to the user. The credit of your expectation is not based on how long the office of a particular telephone company will be inoperative, you ask yourself how long you can afford the lack of a good telephone connection. It is to this model that information technology services should move. The internal structure does not matter to the user. The credit of your expectation is not based on how long the office of a particular telephone company will be inoperative, you ask yourself how long you can afford the lack of a good telephone connection. It is to this model that information technology services should move. The internal structure does not matter to the user. The credit of your expectation is not based on how long the office of a particular telephone company will be inoperative, you ask yourself how long you can afford the lack of a good telephone connection. It is to this model that information technology services should move.

Problem 4: You are losing knowledge

The last problematic practice that we will consider is the loss of initial knowledge. A purely human weak spot, and frankly, it is difficult to specifically address it anywhere. To understand this, let's look at the usual case:

Aaron works in the IT department of his organization. He has been here for three years and is responsible for a number of system and infrastructure components. One of Tuesdays, a specialist from the help desk of their own company contacted Aaron:
“We give you a ticket related to the Oracle system,” the phone said, “Once every two months, it starts to behave unpredictably and it is necessary that someone figured it out with something. ”
“But I'm not an Oracle expert,” Aaron replied, “Jill has the Oracle system.”
“Yes, but Jill is on vacation for another two weeks. You need to do this. ”
“But I have no idea what to do!”
“Well, think of something ... the Executive Director will be very unhappy if this drags out.”

Unfortunately, too much knowledge accumulates in the minds of individuals. In fact, an even sadder truth is the way many companies “cope” with this problem - by refusing some IT professionals full holidays, not allowing them to engage in any other activity that takes them out of sight and reach - such as like training outside the company, trips to conferences, just everything that continues their education and allows you to acquire new skills.

You can count on the fingers of the companies that have made half-hearted attempts to build “knowledge bases”, in the hope that basic skills can be transferred to electronic documents, saved and made more accessible. The problem is that many IT professionals are not necessarily good writers, so the process of filling the knowledge base for them will be very difficult. In addition, it takes time, which the organization is extremely reluctant to devote for this purpose, especially in the face of daily urgent tasks and requirements.

As I said, this state of affairs is difficult to fix. The IT service understands the situation, and as a rule, agrees that something needs to be done - but they are not technologists, and often have extremely limited abilities for this. You can usually create some management requirements that reflect that problems and their solutions must be registered in the form of tickets on the help desk, but searching in such a system can often be difficult or time-consuming - just like it happens When searching on the Internet with all the wrong results, which are immense on the screen during the standard query procedure.

But we must find a way to solve this problem. Knowledge of company infrastructure - and how to solve problems shouldbe accumulated and stored. This requirement will not only help to quickly resolve emerging issues in the future, but also help prevent their occurrence, allowing you to make more informed decisions in the field of IT.

How accurately does unified management fix problems?

This book is about how to fix these four annoying moments, and the methods that I propose for this can be collected under the umbrella of the consolidated concept of “unified management”. At its core, unified management boils down to putting everything together in one place.

We will demolish the boundaries of “specific principalities” between separate IT disciplines, put everything we need on one console, force each specialist to work on one common data set, and force everyone to work together on the problem. We will do this in a way that brings together users, IT and managers into a single window of IT services and performance. We will add more transparency to things like service levels, allowing users to seewhat happens in their environment and be more informed.

We will provide our users with information that they will understand, instead of using the obscure, purely technical metrics that we use in our back-end. We will rebuild the whole concept of SLA, into something that makes sense primarily for users and their leadership, which will allow us to withstand the transition to “hybrid IT”, where difficulties in the outsourcing of some IT services to the “cloud” are inevitable.

As a result, we will find a way to collect information about our environment, including ways to resolve incidents that will allow us to save time in the future if we have such questions again. In addition to this, this information will enable management to make better decisions regarding the choice of future technologies and investments.

We will try to do this in such a way as not to force the organization to sell part of its employees to the authorities, and also will not require half the life for implementation. Of course, this will require some creativity, including the search for outsourced solutions. The idea of ​​outsourcing monitoring for internal systems is relatively new, and we will see how applicable it is.

I must emphasize that most of what we will consider will help to cope with the support of those management frameworks that many organizations are already implementing today, including ITIL, which has become popular in recent years. You do not need to be an ITIL expert to take advantage of the new processes and techniques that I offer - you don’t even have to think about implementing ITIL (or any other framework), unless your organization is already doing this. But if you already use a set of organizational procedures, you will be pleased to know that everything that is offered in this book will fit perfectly into them.

Conclusion

This chapter lists four main topics that will be covered in the remaining chapters of this book. And their basis is what many experts consider the most serious and fundamental problems that IT has to deal with today, and it also contains a number of things that we will concentrate on the ways to fix in the remainder. We will pay attention to changing the management philosophy and practices used, not only through the selection of new tools, although new tools can be just the foundation that you will choose to implement these new solutions.

Chapter 2 will be devoted to the first problematic practice, which consists in managing IT infrastructure for individual sites. We will look at the technological reasons why organizations are more or less forced to follow this path, and explore the directions you can start from to change your current practice.

Chapter 3 will look at related people: IT executives, your users, your service desk, and so on. Only the general involvement of all employees in the process can enable IT to better adapt to the needs of the organization.

Our third problematic practice will be the subject of discussion for Chapter 4, where we will dive into the search for the externaldata center for monitoring. The final goal will be to solve the problems that we will discuss in this chapter, focusing further on the value created by IT for our organization.

Chapter 5 will look at ways to turn problems into solutions. Although modern organizations are fully aware of the need to track information passing through the help desk and build a knowledge system, the ways in which these processes are managed as part of the overall IT management system can be a big difference compared to the originally planned added value.

The final conclusions will be made in Chapter 6, where we will attempt to visualize the IT environment, which uses new, unified management practices. I will also provide a series of stories to help you see how these updated practices work in real life.