Summary of one failed Customer Onsite software implementation experience

Subsequent article: the transformation of grassroots programmers into project management (16 and 7) teams started in 2013

After three months of busy work, our team's problems finally leaked during the customer's on-site implementation.

On the evening of June 16, the sleeper arrived in DEF city on the second day (16) and went directly to the customer's site to implement the system (called system ). On the first day, it was still relatively calm, but the subsequent things were one by one, which made me feel that there were no two travel experiences in the world again.

Because the customer does not provide a separate server, it is deployed on the same server as another software system (called system B) of our company. During my deployment, the SQL server on this server suddenly terminated the service abnormally and appeared three times. The customer directly found me, ask me if system B is not working properly because of my system deployment. Once I hear this, I guess the next work will not be well carried out, obviously, the company's business talk with customers is not very harmonious. Later, I explained this to the customer and told them that system B will encounter similar problems. You can first check whether the SQL server service is terminated abnormally on the server for troubleshooting. It is initially determined that SQL server2005 is not installed, resulting in service termination from time to time. Plan to reinstall the database. This level is barely easy, but the next thing will be twists and turns.

The customer's database server version is SQL server2000, and the computer hardware is slightly different. Because the industry we target is the peak of software use every year from April 1st to April 1st. After I deployed the three iis applications involved in system A with A gis service, the customer looked for it again and asked if we set up system A to affect the database server, their old software was stuck for a while. In the face of this problem, I made the following analysis: first: on the SQL Server is only the corresponding database access card or all database access cards (because there is a master database that is accessible by almost all industry software ), later, it was confirmed with the customer that the card was killed by a single database. Second, we opened the event viewer that comes with SQL server and checked the items to be monitored for real-time monitoring and analysis. Later, we found that system A does have some empty database operations, in addition, there are multiple requests within one second, because the underlying usage of system A is spring.net, and the customer did not look for them at the site. I decided to use another product C (Standard Business Database real-time data synchronization software) of our company because it took too long to solve the problem at the customer's site) on the application server, the Business Database on the database server is exchanged to the new database service in real time. The impact of system A on the original business database is almost reduced to zero. When using the database event monitor, system A does not initiate any request to database 2000. However, the 2000 database will still cause the crash of their business system, but now their old system is barely running. I taught the customer how to use the SQL server Event Viewer so that they could learn to analyze the cause of the choppy, and the customer also agreed that even if the system is not running, their libraries also consume an increasing amount of memory, resulting in choppy old software. It can be inferred that, even if the SQL server consumes the same memory, the impact on the application may be different. The optimization and adjustment of the existing A system will be discussed later.

Then, the deployment process of system A was "disgusting, mother-to-death, home, disgusting", which exposed one problem after another in our team, now the team of 20 people is in disorder. The problems in team management are the most direct cause of this failure. The regression test of the released version is seriously insufficient. The project owner did not participate in the test process. The chaotic management of results and things does not meet the minimum requirements of results and things management. The lack of documents poses a huge cost risk to the team. Everything is in the programmer's mind, which is a terrible thing; the code is not properly checked, and the encoding requirements of the Three-rule and five-statement cannot be implemented. The log records are not properly matched and scattered, leading to no log output after an error, it has a huge impact on Troubleshooting; and so on, all problems are so obvious. As a result, the system deployment and customer communication work should have been completed within one to two days. After four days of continuous overtime, the ideal release version is still not available.

Through the on-site implementation system experience, some problems were encountered and some problems were exposed. Problems and leaks are not terrible. The key is to follow up the subsequent summary and team adjustments. Follow-up will continue after business trips are returned to the organization. I will share the results and hope the software team with similar development experiences will take it as a warning.

We hope to communicate with more software peers, exchange ideas, and make common progress.