The day starts with a check of my calendar tasks for the day, then a review of email followed by modifications as needed deal with unexpected tasks that arrived overnight. Today I started working on a conversion of MPLS carriers for one of our clients with the task to complete cross connects between the data center and the client’s rack. Then I jumped over to making modifications to several phone extensions for another client to update call flow routing after a staffing change. At this point most of the rest of the day is scheduled to work on the MPLS cross connect and router configurations which is critical as the circuit turn up is planned for tomorrow. I then jump over to check on the status of a new site turn up in South America that we worked on last night.
Author Archive
Network documentation is like a lifeboat, of little interest until the network fails, then of great importance. The worst case is when a network remains totally down while staff searches for information to login or configure replacement hardware. I have seen businesses lose a whole day of productivity to rebuild equipment that could have been easily done in less than two hours with proper documentation. A recent example is a firewall repair that took four and a half hours to fix, but that time was made up of thirty minutes to fix and a four hour wait time to get the login information. During this failure the end users experienced an outage five times the length it would have been if the information was readily available. Additional time is then lost explaining to executives the estimated time to resolve and what changes are going to be made to avoid the problem in the future, with discussions often taking time away from the repair.
Peter CookEnterprise Engineer
