Support Engineer Manifesto
Currently, there are a large number of good software solutions. Why are only few of them successful? In my opinion, for the most part, the reason is that they do not fit well enough into large corporate infrastructures managed by ITIL.
In order to provide a good quality corporate solution, it is not enough just to make a solution that implements a business process. A customer needs more than just a solution in itself. For its part, the customer understands that he will need to exploit, maintain, monitor this decision. It is possible, even to integrate it with existing ones, to deploy new installations, to restore fallen ones, to make an analysis of crashes, poor performance, and similar support and maintenance tasks. Another property of solutions consisting of a large number of components is the ability to provide information about itself, to be self-described. If the solution consists of a large number of interconnected components that run on a large number of servers, it will be very good if such a solution provides an interface that will allow you to automatically find out where and which component is running. Even if the component was transferred from the server to the server, information about such changes should be provided automatically. In the case of a ready-made ITIL-based system in the company, such information should enter the system itself without external intervention. This will reduce labor costs for integration, monitoring and support of the solution, simplify processes, will allow to get rid of the chaos and manual update of application catalog data
The Windows platform, in turn, provides technologies designed to create solutions considering the need for support, operation and inventory in the future.
')
When a software solution consists of a large number of interconnected components that run on a large number of servers, some command line interface is needed to manage the solution. These components do not necessarily exchange data with each other, but generally represent a complete software solution. For its part, this command interface should provide scripting capabilities. This is necessary to facilitate and automate routine decision support tasks that are bound to arise. In addition, such an interface should make it possible to search and find in the existing sea of components and servers the right server and the necessary component. In essence, the basic set of tasks that it should help to solve are:
All this in the Windows environment can be implemented on the basis of the WMI interface. If the solution and its components are bound by WMI classes that provide similar functionality, it is easy enough to get a command-line scripting interface based on PowerShell. It will not be difficult to generate PowerShell cmdlets based on these classes, which will give this very command line interface just like that. For solutions built on IIS there is no need even for WMI, since IIS itself provides all the necessary functionality. It is only necessary to implement wrappers over it, specific to a particular solution. As a result, you can get a full-featured solution management interface from the command line, which will be fairly simple to integrate with the existing CMDB implementation.
At the same time, an important element here is integration with the ITIL infrastructure of the enterprise. The solution should be initially designed with this requirement in mind. The application must provide the ability to inventory itself and update the information in the CMDB automatically. In this case, all teams supporting both solutions and infrastructure will have complete and up-to-date information on the state of the environment and on the connections between the components.
On the other hand, the CMDB environment must provide an interface that allows you to get these dependencies. This will enable the development of automatic application deployment mechanisms based on knowledge of the existing infrastructure.
Thus, recommendations for developers and architects in terms of product manageability are as follows:
As you know, a software solution can be considered as a service provided by the company. Thus, in order for the quality of this service to be high, it is necessary that the solution can be easily monitored and responding to incidents occurring. Moreover, at best, the solution should be easily integrated with the existing monitoring infrastructure of the enterprise. How to achieve this? There are three main ways from the simplest to the most complex: event logs, event counters, event tracing for windows.
Event logs are the easiest way to provide status information on a component. If an application or software solution reports its status to the log, it can be easily integrated into any of the existing monitoring systems right out of the box.
On the other hand, sometimes the support teams, as well as the developers themselves, need additional information about the state of the system as a whole or its individual component, both in combat environments and in test ones. This is where performance counters come in. When a solution provides performance counters, it becomes much easier to investigate and deal with performance problems. Moreover, all existing monitoring systems can consume meter data and generate alerts based on them. In turn, all this, including the management software interface and CMDB data, can be used to automatically respond to these alerts.
It happens that this is not enough. Sometimes it is necessary to dig deeper and see what is happening on the combat system, correlate events occurring in the system from different sources, from different angles of view. For such purposes, there are mechanisms for Event tracing for Windows (ETW). If the solution provides data on its performance and state through the ETW infrastructure, it becomes possible to conduct in-depth performance analysis.
So, as a result, when designing an application, to ensure simplicity of its monitoring and support, it is necessary:
The cornerstones of Windows deployment are packages. They make it possible not only to easily deploy a solution, but also to roll back an unsuccessful installation, or correct an existing one if necessary. In addition, MSI can be deployed using centralized tools such as SCCM, or even using Active Directory itself. Packages can be built using the Wix Toolset, which provides the ability to build them as part of the solution build procedure.
At the moment there are several new technologies that are designed for deployment: Desired State Configuration (DSC) and OneGet.
DSC technology is a way to build complex deployment scripts in a declarative language. The idea is to describe the desired server configuration in a simple declarative language, more precisely a subset of the PowerShell language, and then instruct the server to apply this configuration to itself. The main usage scenario is when servers access the central point and take their configurations in case they have changed - the version has grown. In the process of applying the server configuration can download additional files, distributions, etc. In order to deploy your solution, you may need to implement an additional component - a DSC resource (DSC resource), which will know how to deploy and configure exactly your component, what parameters and where it needs to be set. This resource is stored at the very central point, the configuration repository, and there is no need to worry about its delivery to the server. Everything will happen by itself.
Another technology that is currently experimental is OneGet. It can be considered as a package manager for Windows environments. Ideologically, this is a framework that can use any external package repository; by default, the public repository is Chocolatey based on NuGet. However, you can implement a provider for any repository used in the company. This approach is a big step forward. Using the repository makes almost any deployment based on file distribution quite simple. In essence, the system collecting the solution will have to put the finished package into the repository. At the moment when the need arises in a deployment, it can be initiated by any centralized means such as SCCM.
Bottom line, when designing an application, to ensure ease of deployment, you need to think about the following:
Links
WMI
MSI
WIX
Oneget
In order to provide a good quality corporate solution, it is not enough just to make a solution that implements a business process. A customer needs more than just a solution in itself. For its part, the customer understands that he will need to exploit, maintain, monitor this decision. It is possible, even to integrate it with existing ones, to deploy new installations, to restore fallen ones, to make an analysis of crashes, poor performance, and similar support and maintenance tasks. Another property of solutions consisting of a large number of components is the ability to provide information about itself, to be self-described. If the solution consists of a large number of interconnected components that run on a large number of servers, it will be very good if such a solution provides an interface that will allow you to automatically find out where and which component is running. Even if the component was transferred from the server to the server, information about such changes should be provided automatically. In the case of a ready-made ITIL-based system in the company, such information should enter the system itself without external intervention. This will reduce labor costs for integration, monitoring and support of the solution, simplify processes, will allow to get rid of the chaos and manual update of application catalog data
The Windows platform, in turn, provides technologies designed to create solutions considering the need for support, operation and inventory in the future.
')
Manageability strategy
When a software solution consists of a large number of interconnected components that run on a large number of servers, some command line interface is needed to manage the solution. These components do not necessarily exchange data with each other, but generally represent a complete software solution. For its part, this command interface should provide scripting capabilities. This is necessary to facilitate and automate routine decision support tasks that are bound to arise. In addition, such an interface should make it possible to search and find in the existing sea of components and servers the right server and the necessary component. In essence, the basic set of tasks that it should help to solve are:
- By the name of the server, return all components of the solution that are executed on this server and their status. This will provide an opportunity to automatically update the application catalog database, which will facilitate support. In fact, this may enable the user to automatically obtain the interaction graph between components of a complex system.
- Perform basic operations on components, such as stop / start / restart, get the status of components, configure them
All this in the Windows environment can be implemented on the basis of the WMI interface. If the solution and its components are bound by WMI classes that provide similar functionality, it is easy enough to get a command-line scripting interface based on PowerShell. It will not be difficult to generate PowerShell cmdlets based on these classes, which will give this very command line interface just like that. For solutions built on IIS there is no need even for WMI, since IIS itself provides all the necessary functionality. It is only necessary to implement wrappers over it, specific to a particular solution. As a result, you can get a full-featured solution management interface from the command line, which will be fairly simple to integrate with the existing CMDB implementation.
At the same time, an important element here is integration with the ITIL infrastructure of the enterprise. The solution should be initially designed with this requirement in mind. The application must provide the ability to inventory itself and update the information in the CMDB automatically. In this case, all teams supporting both solutions and infrastructure will have complete and up-to-date information on the state of the environment and on the connections between the components.
On the other hand, the CMDB environment must provide an interface that allows you to get these dependencies. This will enable the development of automatic application deployment mechanisms based on knowledge of the existing infrastructure.
Thus, recommendations for developers and architects in terms of product manageability are as follows:
- Provide a PowerShell-based command line interface for a software solution.
- Optionally provide a WMI interface. Essentially giving it you can get the first item automatically.
- Provide technical documentation describing the high-level architecture of the solution, the map of interactions between components and detailed documentation on the internal structure of the components.
- Design a solution with an eye on ITIL.
Monitoring strategy
As you know, a software solution can be considered as a service provided by the company. Thus, in order for the quality of this service to be high, it is necessary that the solution can be easily monitored and responding to incidents occurring. Moreover, at best, the solution should be easily integrated with the existing monitoring infrastructure of the enterprise. How to achieve this? There are three main ways from the simplest to the most complex: event logs, event counters, event tracing for windows.
Event logs are the easiest way to provide status information on a component. If an application or software solution reports its status to the log, it can be easily integrated into any of the existing monitoring systems right out of the box.
On the other hand, sometimes the support teams, as well as the developers themselves, need additional information about the state of the system as a whole or its individual component, both in combat environments and in test ones. This is where performance counters come in. When a solution provides performance counters, it becomes much easier to investigate and deal with performance problems. Moreover, all existing monitoring systems can consume meter data and generate alerts based on them. In turn, all this, including the management software interface and CMDB data, can be used to automatically respond to these alerts.
It happens that this is not enough. Sometimes it is necessary to dig deeper and see what is happening on the combat system, correlate events occurring in the system from different sources, from different angles of view. For such purposes, there are mechanisms for Event tracing for Windows (ETW). If the solution provides data on its performance and state through the ETW infrastructure, it becomes possible to conduct in-depth performance analysis.
So, as a result, when designing an application, to ensure simplicity of its monitoring and support, it is necessary:
- Review and select a method for recording status events in the system.
- Provide performance metrics for key parameters using counters.
- Optionally provide information via ETW providers
Deployment strategy
The cornerstones of Windows deployment are packages. They make it possible not only to easily deploy a solution, but also to roll back an unsuccessful installation, or correct an existing one if necessary. In addition, MSI can be deployed using centralized tools such as SCCM, or even using Active Directory itself. Packages can be built using the Wix Toolset, which provides the ability to build them as part of the solution build procedure.
At the moment there are several new technologies that are designed for deployment: Desired State Configuration (DSC) and OneGet.
DSC technology is a way to build complex deployment scripts in a declarative language. The idea is to describe the desired server configuration in a simple declarative language, more precisely a subset of the PowerShell language, and then instruct the server to apply this configuration to itself. The main usage scenario is when servers access the central point and take their configurations in case they have changed - the version has grown. In the process of applying the server configuration can download additional files, distributions, etc. In order to deploy your solution, you may need to implement an additional component - a DSC resource (DSC resource), which will know how to deploy and configure exactly your component, what parameters and where it needs to be set. This resource is stored at the very central point, the configuration repository, and there is no need to worry about its delivery to the server. Everything will happen by itself.
Another technology that is currently experimental is OneGet. It can be considered as a package manager for Windows environments. Ideologically, this is a framework that can use any external package repository; by default, the public repository is Chocolatey based on NuGet. However, you can implement a provider for any repository used in the company. This approach is a big step forward. Using the repository makes almost any deployment based on file distribution quite simple. In essence, the system collecting the solution will have to put the finished package into the repository. At the moment when the need arises in a deployment, it can be initiated by any centralized means such as SCCM.
Bottom line, when designing an application, to ensure ease of deployment, you need to think about the following:
- Build on packages. No need to reinvent the wheel.
- Find out if the company has the existing infrastructure control / repository / deployment and consider it as a deployment environment so as not to reinvent the wheel. Most likely, it takes into account all the nuances and security policies of the company, which on the one hand will complicate, and on the other, simplify your life in the future.
- If there is such a system, use it for deployment.
Links
WMI
MSI
WIX
Oneget
Source: https://habr.com/ru/post/247711/
All Articles