This week, IT Manager Republic will feature the daily diary of Mark Gonzales, IT manager for the department of emergency management with the county government in Pueblo, CO.
Immediately after I walk into my office and sit down, a staff member comes in to ask if I can help print a few address labels. I put aside reading my e-mail from yesterday to assist her.
Then our computer specialist arrives to get the tech meeting started. We both have a busy day ahead. I want to have an off-site meeting and take him to breakfast, but he says he is too busy. I’m not going to push it because I can see the to-do list in his hand and the sheet is filled from top to bottom.
Get caught up on this week’s diary.Read Monday’s installment.Read Tuesday’s installment.
As we are having our tech meeting, our director walks into my office. He asks that we move the computer equipment out of his office so that the carpet guys can get started with their installation.
After completing that task, the accounts specialist informs me that the countywide finance database is not coming up on her computer. It looks like there are problems with the application, so I give our County I&CS (Information and Computer Service) group a call. They inform me that they upgraded the finance software application last night and are having some problems.
It’s time for our database meeting. This is the meeting that I have been dreading all week. Luckily, my fears are largely unfounded because it seems to go okay. At least nobody loses their temper or gets upset.
This meeting was initially scheduled to discuss when and how we would come up with much needed database policies, but because my boss made the decision not to create policies until we were caught up with the data entry, it turned into a meeting where everybody simply updated each other on what they are working on in the database. I don’t completely agree with my boss’s approach, but I understand his concerns.
During the meeting, I receive a lot of feedback on features that the database is lacking. I make a list of the improvements that the staff wants to see, and remind them that making these fixes will again bring a halt to data entry. The last time we had modifications made to this database, the developer had the database for about two weeks.
I go to help a staff member who mentioned in the database meeting that she had some problems and questions concerning a few records. I can sense that this is going to take a while because the stack of records is about one-half inch thick.
I haven’t finished resolving all of the database questions and problems yet, but I need to head off to lunch to meet a couple of college buddies. We try to get together for lunch once a month to stay in touch. I usually take an extra half hour when we meet because I know that I am going to get to hear some of the problems that they are having in their jobs. I hate to admit it, but there is some truth to the phrase, “Misery loves company.”
I am on my way back into the office when the GIS (geographical information system) manager gives me a wave in the parking lot. He wants to know how the database meeting went this morning. I tell him how things are going, and he says that I am doing a good job. That was just the thing I needed to hear after all of the problems I have been having with the new database.
Back at my desk, I finish resolving the rest of the database problems that I was working on before lunch.
The developer of the database calls. He has received my e-mail and wants to confirm our new modifications. There’s good news—he will work on adding the new features tonight and have the database back to me in the morning. The changes are simple and won’t require any major reworking. I zip the file and send it to the developer via e-mail. The staff assistants entering the data will be glad to hear that their data entry won’t have to go on hold for more than a few hours.
I check on some of the Cisco and ping statistics that we take during various times of the week. I want to verify that the numbers taken from these tests are normal, and that we are not encountering any problems. We take the Cisco statistics manually by logging in to our Cisco router and running a few different commands such as ping test, sho ver, and sho int. These commands are run from the Cisco OS command line, and give us information such as:
- How quickly the data packets are traveling in relation to the size of the packets
- The success rate of the packet delivery
- How many CRCs (cyclic redundancy checking) we are encountering
- The number of input packets versus the number of input errors
- The number of aborts encountered
- The number of collisions encountered
We also use a ping script file that contains all of our WAN remote sites so that we can monitor how successful our connectivity is (by examining how many undeliverable packets there are, for example) as well as the speeds and times of the packets. We use these statistics to monitor our WAN performance as well as for benchmark purposes. Taking these statistics manually will have to do until we can get our new SNMP (simple network management protocol)-capable CSU/DSUs (channel service unit/data service units).
Once again it is the end of the day and I have to get to my e-mail and voice mail. I have 28 new e-mail messages and four new voice mails. I had better begin answering some of the messages before I leave for the day.
Post a comment to this article or send us a letter if you would like to write a description of your workweek and share your IT diary with TechRepublic.