Posts Tagged ‘lessons learned’

SaaS Deployment Fail

October 13, 2013 Leave a comment
Push Button Deploy

Remove the human factor from your deployments to avoid mistakes.

Lesson Learned: Automate your entire deployment pipeline and don’t celebrate until you are done.

Most SaaS (software as a service) companies carefully plan and orchestrate deployments as a core competency. Many veterans of these deployments have learned to be good at it through experiencing failures and learning what not to do. One of the greatest learning opportunities is when things go terribly wrong and it takes heroics to correct. This story is one of those experiences.

In 2005 I was the Director of Quality at Convoq, a video conference start-up. We build web-based and desktop video conference tools that enabled applications like to evoke ad hoc or scheduled video conferences (Convoq ASAP Pro). The application was build upon the Adobe Flash Media Server. Customer accounts, their contacts, and conference history was stored in a relational database. We used physical hardware built from ghost images to assure our servers were carefully replicated for high availability.

We carefully planned and iterated on an instance of the Deployment Document for each release. Although we continued to add automated scripting for deployments, we still had to manually start the scripts and we had to add in all the verification points along the way. We also had a final Deployment Document sign-off ceremony prior to commencing any release. We thought we were pretty good at this pattern. During deployments a member from each group and members from IS would assemble in the conference room to work through the deployment document procedure together. The procedure included putting up a maintenance page during an outage, and we worked at making this outage as short a window as possible. We planned our releases to begin at 5pm Wednesdays, since Wednesday evenings seem to be less impact to customers on the west coast, it gave us all night to complete the deployment if things went wrong, and we had the next day with a full engineering staff to address any problems that might result from the deployment the night before. On planned major release days, we brought in beer to celebrate the completion of a release.

One planned release, we began as we normally do with both email and in-product notification of a scheduled release. There was a short outage window expected with this release. It should be very routine. Here is how it went as I recall it…

  • 5 pm ET: We assembled in the conference room as planned and proceeded to execute pre-deployment steps, including putting up the maintenance page. Each step was called out verbally when started and finished, for both changes and verification. One of the changes was a series of SQL statements that would update the schema and add related tables. Order of changes and completing verification of a change must precede the next change. This included migrating some data to new tables and updating the index.
  • 6 pm ET: As we proceeded to execute through the initial changes everything was going well. This seemed routine for us and the were a bit punchy, joking about customers, and having a great time. We were more than half-way through the release.
  • 6:30 pm ET: The last part is a piece of cake and we expected to complete by 7PM ET. We were feeling pretty good about this release and ready to celebrate. So, we broke out the beer. Boy that first gulp tasted good. Things were still going fine as we get down to final testing of these changes. Then, we noticed the contacts for one customer were appearing under a different customer. Really? How can that happen?
  • 7PM ET: The tone of the room starts to change. We check other customer data and find the same thing. We start searching through changes and database queries to figure out what happened. Apparently a database change was made before a prior database change completed. We lost track of verifying start and end to each step and got out of order. I recall that a change was made to correct the problem and made it worse. Agh, the beer must have clouded our minds and we messed up. All the beer went into the trash. We should not be celebrating this early.
  • 9 pm ET: We are still trying to understand the impact of the problem. Phone calls go out to the database experts to get them looking at the situation. We even had a couple engineers come into the office. We also were trying to replicate the problem in one of our test environments. We call spouses to indicate this will be a late night or all-nighter.
  • 11 pm ET: We are clearer about the issue now and believe we know how to correct it. I make a statement that “we just have to be back up by dawn.” 7AM ET is when our published SLA (service level agreement) with indicates when we will complete any maintenance window by this time, and shortly afterwards the CEO arrives each morning.
  • 1 am ET: We made progress with database corrections. However we still have a data problem that needs correcting.
  • 3 am ET: The coffee is not working to keep me awake. I do some pushups on the floor to wake me up and resume verifying fixes.
  • 5 am ET: We believe we have it all solved, but not ready to turn on traffic yet. It’s still dark out and the birds aren’t singing yet.
  • 6:45 am ET: We enable traffic again. Everything looks good. We keep verifying live data and watching logs to see that all new activity looks right.
  • 7:20 am ET: The CEO walks in the office. I’m usually in the office by then, so he doesn’t yet see anything out of the ordinary. He walks by my cube and asks how the release is doing. I told him everything is working well. He said “great” and proceeds to walk towards his office. He stops, looks back at me, and asks if those are the same clothes I had on the day before and forgot to shave, with a smirk on his face. I told him he was right, and then he noticed more folks in the office than usual at this hour. I then had to tell him we had some problems with the deployment that required us to work through the night, but we were live before dawn and met our SLA. He laughs and then asks me to come to his office to explain.

I don’t believe I mentioned the beer in my explanation. I did mention that we would be much more careful about keeping the deploy steps in order next time and automating as much as we could. It was the human element that got in the way of a successfully executed release. Most of our customers will never know there was any problem, and our SLA was met. We came dangerously close to having a far bigger impact to the field. This experience convinced me to strive for automating the deployment pipeline end to end, including validation between steps.


My Biggest Test Mistake

October 13, 2013 Leave a comment

Lesson learned: A one character change can have a very significant impact on quality.

I love to hear and tell stories in illustrating lessons learned. They really convey the emotional impact of the lesson at the time it was learned. This is a story about a very costly mistake when attempting to make a small one character change in application resources that I would never want to repeat again.

In 1993, I was working at Custom Applications on the FreedomOfPress product line. This is a print driver application that provided a software PostScript RIP (raster image processor) for rendering pages to over 150 different printers.  We were releasing a new Mac version for mass distribution to the major software distributors (Ingram, MicroD, etc.). At the time, software was distributed on CD’s from a glass master and silk-screened. This included sending a CD image to the disc duplicator, who created a glass master image, and then stamped out tens of thousands of resin discs. The discs were silk-screened with images and print, and assembled into a printed box along with its printed manual and other material.

Macintosh-centris-660avA blockbuster release of the new Macintosh Centris 660 AV was was the hottest thing in desktop publishing and the CEO had it in his office. We were able to get Apple hardware ahead of distribution to develop and test with the hardware, so we only had one. We had a chance to test with it at times and didn’t have it available to us at all times. As we were preparing for the trade show that Apple was unveiling this new hardware we were received registered trademark ® certificate. Of course we had to have this symbol on our box and on the software! The marketing department was all over this.

We received a request from marketing to add one last change and test, on the day we had to send out the disc image for duplication. This was only a one character change, right? How hard could it be? Our application artwork was created on a Solaris work station and saved to the Mac as a resource. We were asked to add the ® symbol was the splash screen when you start up the application. The text was updated on the Solaris workstation and saved to the Mac (as we normally did, right?). We built and spot checked this new version with the ® symbol proudly displayed on the splash screen on machines we had in the lab. We then sent the new disc image to the duplicators by overnight courier.

The next morning the CEO comes into the office and installs the new version of FreedomOfPress onto the Centris 660AV. He launches the application and the splash screen appears first…the system restarts. What (?!) he says to himself…he thought he must have done something wrong. When the system comes back up he tries again with the same result. He calls me in and explains what he experienced and shows me what is happening. Wow! How did this happen and how did we miss this? Well that machine was nicely tucked into his office when we were testing permutation of machines and printers the day before.

The VP of Engineering was called in and we discussed what might be the issue. After all, we only made one character change from what was running properly on this machine only 24 hours earlier. This is bad…very bad. All the engineers involved in making this changed looked carefully at the code and resources and diff’ed the files. Ah, there is one difference other than the ® symbol. A control+D symbol appears at the end of the text file. This was a normal file termination character for the text file created by the editing application on the Solaris workstation. This control character means something very different on a Mac however, instructing the computer to reset. Ouch! We had to stop the disc duplication immediately and get a new image to the duplicators.

Marketing calls the disc duplicators and they find out that the duplicators had already created the glass masters and proceeded with high speed manufacturing of the disc copies. They had already created thousands of copies. Agh, they had to stop the line and these masters and copies had to be trashed. After removing this control+D character, we spent that day testing through this disc image again, including the Centris 660AV. The new image was sent out to the duplicators overnight again and they rushed through the order. We were able to get the new product boxes to the trade show just in the nick of time.

This was an expensive one character change. As it turns out, there was a corner cut when making this change and the text was not re-editing and saved on the Mac before adding the resource to the bundle. If this step was not skipped, the control-D would not have appeared in the final resource file and this problem would not have been introduced. Also, we should have included the new hardware in the list if things we had to verify.

The real lesson learned here is to pay very close attention to the proven process and not cut any corners when making even simple changes, especially when making a seemly benign change at the last moment.

‡ a.k.a. ColorAge, purchased by Splash in the late 1990’s

%d bloggers like this: