Pages Navigation Menu

Technologies Are Made To Serve Human Being

System Maintenance & Development – Peace of Mind

Ensuring operational continuity of constantly improved systems is a great challenge both in terms of technology and management.

The real life of a system does not begin until it is put into production. This is when most software vendors believe they have completed their work for their Customers. This is a very sophomoric approach: install the product, get paid, and go home.

We take a different approach. We believe that we do not even begin to take responsibility for what we deliver until it goes live. Our systems are covered with extensive support that includes:

  • Bug submission support
  • Implementation of minor changes and fixes (UI optimization, performance, etc.)
  • Implementation of major functional changes (development).
  • System supervision and maintenance.

At our Company, we are not divided into teams that only deal with either new applications or maintenance. Our teams support the applications they themselves have developed. This approach provides essential business knowledge and valuable feedback about a given project. Our programmers can then use what they learn from bugs and required optimizations to create better systems.

Support for Submission of Application Bugs

No application is bug-free, so we have devised a process and developed tools that enable us to solve problems quickly and efficiently. The process consists of:

  • Analyzing the submitted problems
  • Implementing patches
  • Testing, including regression testing of the entire application
  • Getting the patches accepted by the Customer
  • Installing a new version in the production environment

First Tier support, i.e., accepting bug submissions, is critical. Regardless of the submission channel the initial analysis of the problem and the means of communicating with the person who submitted it will determine whether it is going to be solved promptly or escalated (making end users resentful and frustrated).

At this stage, we reject submissions that:

  • Do not pertain to our application
  • Are a result of external system failures
  • Are a result of the submitter’s software not running properly (viruses, browser add-ons, network issues etc.)
  • Require application changes that do not comply with the current specification (these are usually system enhancements supported by another process).
  • Have already been submitted (duplicates).

Confirmed, precisely described, and repeatable errors are forwarded to our developers for analysis. For a programmer who knows the source code well, applying an error fix is a relatively simple task. Automated unit and functional testing ensure that these fixes do not introduce other errors.

Upon completing the programming task, the patch is verified by our testers, and then presented to the Customer for acceptance. In the final stage, a new application version is installed in the production environment.

Support for Minor Changes and Fixes

Large Web applications require minor changes and support for issues that do not result from system bugs. These are usually webmaster tasks, copy corrections, graphic components, etc.

Support for Major Changes

Dynamically changing business requirements, legal regulations, and user expectations mean that applications constantly require the addition of new functions and/or the modification of existing ones. Every such change is supported independently at each stage – from the definition of the functional requirements, to design, implementation, and testing, right through to implementation. Having a team that knows the system inside out and backwards means that the necessary changes can be implemented quickly and efficiently without conflicting with other changes and fixes.

Change Stream Management

All the above changes can be simultaneously implemented by different programmers and by submission, management, testing, and acceptance teams. However, the expected outcome is a single application version that includes those changes accepted by all stakeholders. This is installed in the production environment. Experience shows that situations where one of several changes in an “almost complete” version has to be cancelled are quite common.

In order to deal with this, our management model involves implementing all changes in separate code branches, which are merged into a “release candidate” before final testing. Withdrawal of one change requires building another release candidate with a different scope of changes. The complexity of this process is shown on the diagram below:

GIT significantly streamlines code changes and allows them to be moved quickly between individual branches to create new branches, merge existing ones etc. The conventions for branch naming, commit descriptions and version management, and the meticulous check-in of changes in the management system eliminate any unexpected situations, ensure the availability of all changes and enable the full context of each line of code, that is, the programmer, premise and submitter (source of requirements), to be determined.

Application Maintenance

Application maintenance aims to prevent errors and failures before they occur. This is a clearly stated policy at Webtecsolution SA – where the Customer is treated as a business partner. We know only too well that a system failure and unavailability can result in measurable losses. We manage to proactively avoid such situations.

The application maintenance team performs periodic system reviews in addition to work commissioned by the Customer and bugs reported by users. These reviews cover:

  • Verification of operating parameters of databases, application servers, workloads etc.
  • Log inspections to find rare bugs not submitted by users
  • Application performance analysis to determine whether new versions adversely affect the application under workload and whether the application is capable of serving an increased number of page views.

[/box ]

The result is optimized code and minor fixes. These are tested and then installed with the new application version in a production environment.

System Operation Monitoring

The key component of system maintenance is monitoring and registering its operating parameters in the production environment. A meaningful system analysis requires as much information on its individual components as possible.

Why Monitor System Operation?

For us, the main aim of system monitoring is to avoid failures. With appropriate monitoring, we can usually detect the first symptoms of impending problems and prevent them in advance. Should a failure still occur, then monitoring data help us diagnose and remedy the problem and prevent its recurrence.

System monitoring allows us to determine whether another application version has similar stability and performance (resource utilization) parameters. The same goes for changes introduced during a reconfiguration or expansion of the hosting infrastructure. Without proper monitoring, we wouldn’t be able to decide whether a change to an application, configuration or piece of equipment had delivered the desired outcome.

Observing parameter changes over a long period (monthly, quarterly or annually) enables us to schedule application optimizations and system configuration changes, and to decide whether the equipment should be expanded.

What Components are Monitored?

Not everybody is aware of the complexity of a modern Web system environment. This typically includes:

  • HTTP server, application and database clusters.
  • Servers supporting these clusters.
  • Operating systems.
  • Network devices (switches, routers, firewalls etc.).
  • Storage systems.
  • Backup systems.

In addition, all these components exchange information in complex ways. For a typical system, we collect data on the hundreds of parameters that indicate its current state. A complex infrastructure can have thousands of such parameters.


Effective monitoring of a complex system environment requires appropriate tools. Contrary to popular belief, commercial tools are not the best choice (due to their price and lack of flexibility). We have therefore selected a special blend of in-house tools and Open Source solutions.

It is not feasible to manually analyze the huge amount of data collected during system monitoring. That is why we use R, a statistics package that lets us quickly perform basic examinations (correlation analysis, parameter distribution, etc.) and even program more complex analyses. We put great emphasis on appropriate data visualization, as a single diagram is worth more than a thousand lines in a log file.

Our many years of experience have taught us how to select appropriate parameters for observation. We can now evaluate the state of a system by using a few reasonably selected diagrams.