You cut what!!! Tech Support |
- You cut what!!!
- Get the desk top tech here NOW!
- Activate my SIM!
- Database Support 17: A Real Forking Pain
| Posted: 25 Oct 2019 08:40 AM PDT So this didn't happen to me but rather a coworker at the time. I am going to tell it the best I can. My coworker and I worked on a help desk for tier 1 troubleshooting at a financial institution. We only took calls for internal clients and the actual stores around the country. We did internet troubleshooting, printers, phones, and DSL lines. So we always had the usual "The computer doesn't work" when it was really off. Now on to the main event: My coworker got a call from a center stating that their internet is down. He pings the router and all is good. However he is unable to ping any of the computers. He gets them set up on the back up Dial-Up. The store calls him back their cell phone. He continues to work on finding the reason for the outage. After about an hour of troubleshooting they decided to start again the next day. The next day arrives and he continues to troubleshoot the issue. Eventually he had the store trace the wire from the router to the switch and ensure that they are plugged in properly. Connections on both ends are good. Well that's a no go. He is asking some questions and finally the store said the following: Store: "Recently we did some renovations and there was a blue cable going across the top of the door and we cut it so they could paint the wall." You could hear my coworkers soul just break. He put them on hold and took off his headset and looked defeated. After a minute he got back on the phone and asked them why they just cut random cables. They responded that didn't think it was important. Eventually we ended up getting a technician dispatched to their location to fix the issue. Moral if the story: Don't cut random cables. [link] [comments]  |
| Get the desk top tech here NOW! Posted: 25 Oct 2019 04:22 PM PDT TL: DR at the bottom. Many moons ago i used to work for a Mega Global Corp Financial Institution. This company had a mandate to make obscene amounts of money and didn't particularly care about anything else. So this meant they spent money to make money because they knew it would more often than not come back to them ten fold. I was a lowly level 1 helpdesk monkey in my first few months on the job. Working in an entirely different country to the staff I was supporting and this was pretty evident by my Aussie accent. That's how much money this company had. It was cheaper to build a whole support operation that worked 24/7 in another country and have them be the 1st and 2nd level support for the hundreds and thousands of staff, than to do it locally in each office. Anyway. This one shift I get a call from a finance trader in one our most important trade locations. A couple of things to know about this location. All finance trading was done via computer there, we had so many traders there that the "trade floor" was the size of a regulation American football field, and there were so many screens (often 4-8) for each person there that the building didn't need any heating system and in fact during summer the roof could be jacked up and open to allow the waste heat to escape. So back to the call. $Me: Good morn.... $Trader: Shut the fuck up. Get the fucking guy here to my desk right fucking now! $Me: Uhh sorry, can i get a description of your issue please? $Trader: Jesus fucking Christ, I'm right near the Starbucks kiosk, just get the guy here right fucking now! click Oh yeah did i forget to mention there was a Starbucks franchise on the trade floor? Because there was. Money baby, yeah! Cut to a perplexed and a little frustrated me. Thank God our phone and ticketing system talk to each other and pre-populated the traders details and location otherwise I'd have been really screwed. But i was still a bit screwed. The trader has just hung up on me and all I know for creating a ticket for the local tech's is that this guy needs someone. Depending on the issue there are different tech's that will visit the desk. If it's network related we send the networking desktop tech. If it's hardware.... You get the point. I take a stab in the dark and assign a ticket to the hardware team, and to cover my butt I message their chat group and tell them the ticket is on the way and I'm sorry but the trader didn't give me any info which is why there is none in the ticket. They acknowledge it and say they will take a look but in future try and get the info. I then move on with my life, and take another call. About 3 hours later at the end of my shift I get a bit curious about what the hell happened, so i go back to my child tickets and find the ticket for that pissed off need it right now trader. I can see that the hardware guys swapped out 2 screens. That's kind of unusual. A screen swap is fairly common, but 2 at once isn't. There weren't any other notes though, but i can see who went and did the replacement. So I drop him a message. $Me: Hey I just wanted to check in about ticket 12345. I'm really sorry it had nothing in it. The guy didn't tell me anything and hung up on me. $Tech: Oh him, HAH yeah! That was hilarious. Don't worry about it. It's all good now. $Me: Oh that's good to hear. I can see you ended up swapping out 2 of his screens. What was the issue? I'm trying to work out if I missed something when he called. $Tech: Oh there wasn't really anything wrong with them he just wouldn't let me clean them. $Me: Come again? $Tech: Yeah a bird shit on his screens and he just wanted them swapped out. So I did it. It's all good. $Me: Wait....... What? A bird shit on his screens? $Tech: Yeah we think it was one of the pigeons, they really went to town on his desk. Anyway have to go. One of the pigeons.... inferring that there are at least two and possibly more pigeons. And why single out a particular breed of bird? Wouldn't saying one of the birds be enough? As I have done in the past when there is fuckery about I bring this up with my manager. Turns out, during the spring and summer when they open the roof, birds of all kinds will often fly in and spend a few days just taking a little birdcation in a nice safe place with easy access to food (people's desks) and water (fountains) but will sometimes be literally crappy guests. Most of the time they don't bother trying to get rid of them because they will leave on their own. But that changes drastically if a seagull is spotted. Then they have to call a guy, who was not cheap. I mentioned this was a Mega Global Corp Financial Institution right? We had the money, not a problem. TL:DR Take a call demanding desktop support with no other information at a physically big site. Send desktop support who replace two screens which is strange. Speak to desktop support. A bird shit all over the screens. Not an uncommon occurrence at that site. [link] [comments]  |
| Posted: 25 Oct 2019 04:57 AM PDT I work tier two tech support for a number of customers. One of the many, many things I do in this capacity is manage the cell phone subscriptions of a subset of these customers. Also, most of these customers have internal rules about how to maintain infosec when travelling to high-risk countries, including using a basic cell phone, and swapping their SIM card. Ticket: I am travelling to <high-risk country>, and need you to activate SIM card number # on my cell phone number please. Me, having checked the customer account wherein the end user's phone number was not listed: We cannot do that for numbers other than those on <customer> account. Please talk to your carrier about this. <closes ticket> End user, reopening ticket: Do you mean to say that only users with a mobile phone from <customer> can have mobile service while in <high-risk country>? How am I supposed to communicate with the rest of my delegation? Me: No, we do not mean to say that. We can only help you with phone numbers on <customer>'s account. We have checked both for your name and your number - <phone number> and not found it on the account. Because we are not a mobile phone vendor, we can not activate SIM cards belonging to other accounts than that of <customer>. <closes ticket> End user, reopening ticket again: My phone number with <carrier> is in the name of <other name>, my partner, as it has been for the past ten years. If you search for <other name>, you should find the number in the account. Me, having confirmed that their partner is also not listed on <customer> account: We are unable to find her name on the account, too. We repeat that we are ONLY able to see subscriptions under <customer> account, and regret to say we can not help you in this instance. If you wish to activate the specified SIM, please contact your carrier. <closes ticket> At this point, I was fed up, and decided that if they reopened the ticket again, I would close it without response, and ask our contact person at <customer> to have a talk with the end user. Fast forward thirty minutes: End user, reopening the ticket yet again: What do you mean you can't help me? I'm leaving for <high-risk country> in two hours, and demand that you activate the SIM card RIGHT NOW!!! Me: <closes ticket, confirms that our contact person has left for their long weekend, and send a low priority email to them asking them to please have a word with the end user> [Find all my Tales from Tech Support here](http://www.reddit.com/r/talesfromtechsupport/search?q=author%3Arazumny&sort=new&restrict_sr=on) [link] [comments]  |
| Database Support 17: A Real Forking Pain Posted: 25 Oct 2019 02:06 AM PDT Last time on Database Support: Init one, Perl two. The second portion of my internship at good ol' TLA was done under the supervision of two individuals with only slightly better computer skills than SweetBoss. One of them, DottedLine, was a cheery middle manager who became my "dotted line boss" for the remainder of my internship, and the other, Grumpy, was a dour employee in his 60s who'd been at TLA for decades, had a very particular way of doing things that worked perfectly for him thankyouverymuch, and was to be the target of my new project. Both DottedLine and Grumpy worked in...well, I don't actually remember what their day jobs were, but they had something to do with shipping people and stuff around between offices. And whenever people and stuff got shipped around, it was tracked in a single source of truth jealously maintained by Grumpy: The Spreadsheet. The Spreadsheet was a huge Excel document that took an irritatingly long time to load and existed in multiple versions floating around on various shared drives at any given time, and Grumpy refused to let anyone else make any changes or improvements to The Spreadsheet (or the process around it) whatsoever. I hadn't yet seen it for myself, but several different employees I'd talked to had mentioned The Spreadsheet (complete with the Audible Capital Letters) while explaining their duties, and they'd all had a defeated tone in their voice when describing working with it. DottedLine was understandably kind of sick of dealing with The Spreadsheet, so when I'd mentioned in an earlier chat with him that I'd taken a course on databases in school, he immediately perked up and asked me all sorts of questions about databases, how they worked, how close they were to Excel, and so forth; by the end of our chats, he was as conversant on the basics of databases and the benefits of using them over spreadsheets as a non-technical government employee could be expected to be (which wasn't much, granted, but still). Apparently, while I'd been finishing up my policy report with SweetBoss, he'd gone to Grumpy and tried to persuade him to let me try to replace The Spreadsheet with a database. Grumpy had initially refused, of course, but DottedLine targeted his weak spot: having multiple versions of The Spreadsheet floating around meant that inaccuracies crept in and people had to come to him to resolve discrepancies, a task he constantly railed against, and DottedLine argued that having a single database accessed from multiple places would prevent this. Grumpy could hardly say no without admitting that fixing discrepancies wasn't all that bad, so he grudgingly agreed to give me a crack at it--but only on the condition that he would have final say over the end result and I'd have to honor all his requests for features and such in addition to DottedLine's own requests. Now, I didn't know all of that had been going on in the background when DottedLine gave me his rather vaguely-worded pitch to improve The Spreadsheet, nor was I told that he wanted me to whip up a database to replace it, instead of just sprucing it up a bit, until I'd already agreed to his proposal. I imagine I looked much like the proverbial deer in the headlight of an oncoming train when I was informed that I'd be working on a project that not only couldn't simply be scripted away but was also already making Grumpy even grumpier by its mere existence. Oh, and of course at this point I had (A) never actually worked with a database before, only learned about SQL and database theory in school and run maybe a handful of toy queries against a test database and (B) never written a robust, scalable project to be used by someone else, just homework projects that didn't have to scale beyond the assignment and personal projects that could be as hackish and idiosyncratic as I wanted, so I was more than a bit leery of this whole thing. But DottedLine assured me that he had full confidence in my abilities, and hey, trying something new and potentially crashing and burning is what an internship is for, right? So I smiled and nodded and swallowed my misgivings and asked for a copy of The Spreadsheet for research purposes. After spending most of the afternoon perusing it to familiarize myself with it, I came to one indisputable conclusion: The Spreadsheet was an utter monstrosity that should never have seen the light of day. It contained dozens of sheets, each with hundreds of columns and tens of thousands of rows, which explained why it could take upwards of half an hour to load on the rather anemic desktop machines everyone was working with--and even after a thorough examination I couldn't have told you what purposes over half of those columns served or why they needed to keep every row from the beginning of time in the same spreadsheet. Cryptic abbreviations littered the sheet, both in column and row headers and in the data itself, so for new employees (and yours truly) it was basically a wall of indecipherable gibberish at first glance (and, frankly, at second and third glance, too). Many cells were highlighted with various colors to indicate some sort of status information, but this brought more confusion than clarity because there were multiple shades of each color in use. In some cases it was because Grumpy felt that, for instance, three slightly different shades of red were needed to convey some unfathomable nuance in the data, and in the other cases it was simply because not everyone who used The Spreadsheet bothered to match the colors exactly, and of course there was no way to tell which was which except by asking Grumpy about each one. Worst of all was the formatting consistency, or rather the complete lack thereof. In a column containing dates, for instance, the date "October 1st, 2019" could be recorded in any of the following formats or one of many wonderful variations thereupon:
...and that doesn't even count typos like "1th October" or mistakes like shifting a bunch of cells one column over so a not-at-all-date-formatted value ended up in a date cell. Once I finished my perusal and picked my jaw up off the floor, I went back to DottedLine with what I imagine was a rather shell-shocked expression on my face.
whistles innocently
So I got into the office bright and early the next morning and started googling. I learned what Access was. I learned what Visual Basic for Applications was. I started teaching myself how to use both. I wrote scripts to parse the Wild West of data that was The Spreadsheet--thank the gods for the "export as CSV" option--and slowly, ever so slowly, imported it all into a standard and consistent format to be used to create a database. I even created a nice slick GUI that was so simple even a particularly dim chipmunk could use it fluidly...and then dumbed it down further, with a bunch of big obvious buttons and text fields with input restrictions and so forth, so DottedLine and Grumpy could use it too. On the whole, Access and VBA weren't the worst things I'd ever worked with, and if that was all there was to it I wouldn't have bothered writing up this tale. But remember how I answered to both Grumpy and DottedLine on this project and had to keep them both happy? Well, the two of them disagreed, strongly and frequently, about how things should work in this brave new database world, so throughout the process I was barraged with conflicting requests. Date formats, display colors, column ordering...now that they were starting fresh, both of them wanted to make a bunch of changes to the former logic to make things easier to use (for a given value of "easier") and both wanted to add things in that would have overtaxed The Spreadsheet before, but they never quite agreed on exactly what those changes and additions should be. Attempting to resolve the conflicts was quite a pain, since they took their sweet time with that; the two of them kept different work hours, didn't want to discuss anything over email where you could prove they'd said something specific and hold it against them, didn't want to take time out of their schedule for meetings for what was still "just a low-priority intern project." And each thought that I should answer to him first and the other guy second, so I couldn't just default to one's or the other' request to short-circuit the issue. The only feasible solution to that given the tools I had available at the time was to fork the code into multiple parallel versions and work on them concurrently, since I couldn't install any sort of source control (and had no experience working with source control at the time even if I could have used it). At first, I only had to maintain two versions of the database code at the same time, and it wasn't all that bad. I had a base version of everything named I'd demo both alternatives to each of them, they'd ponder and/or argue the issue between themselves for a day or two, one of them would tell me what they'd agreed on, I'd confirm that with the other one, and I'd fold the correct set of changes into the main version and delete the copies. Effectively, it was a very slow, inefficient, and manual version of git branching and pull requests before I even knew what Git was, but hey, they were paying me by the hour, waiting on them to make decisions was fine by me. Until of course the features they wanted got more complex, such that it would take them longer to decide on which version to go with--multiple days instead of most of an afternoon--and I'd have to start working on one feature while the other one was still in limbo, either because they were just taking too long to decide and I didn't want to waste too much time or because they couldn't decide on how the new feature interacted with the old feature and so they wanted to see multiple permutations. The set of copies I had to maintain grew from this:
...to this:
...to this:
...and so on and so forth. The slightest update to any of the files had to be copied to similar versions of all the files, usually by me booting my live USB at the end of every day to propagate all the changes with some fancy Perl or Bash magic 'cause I wasn't about to sit there copy-pasting everything myself. And of course pruning branches as certain possibilities were ruled out (but might come back the next day if one or the other of them changed their mind, of course) was fun too. And then it got worse. Several people in DottedLine's department caught wind of the project when it was around two-thirds finished, and DottedLine felt it necessary to cater to their requests as well despite the fact that both DottedLine and Grumpy outranked them and could have just told them to deal with whatever decisions they made, so in the last couple weeks decision times got even longer and the branching factor went from 2 to 3 to 5 to more. Finally, finally, all the decisions were made, all the features were implemented as agreed upon, and the database was declared finished. A project that should have taken two or three weeks at a casual pace had I been left to my own devices ended up taking a good two months with plenty of overtime, but at last I was able to put the backend up on a shared drive, distribute the frontend to everyone who wanted it, show everyone how to use it appropriately, and get Grumpy to admit that, yes, even he was suitably impressed with the whole thing. I walked out of that internship proud of having started, designed, coded, and delivered my first real-world project under the (admittedly loose) deadline, under (nonexistent) budget, and to the satisfaction of all of my "customers." I fervently hoped I wouldn't ever have to deal with obstructive and unhelpful three-letter-agency employees ever again. Coming up next: Dealing with obstructive and unhelpful three-letter-agency employees...again. Postscript: When I returned to TLA the next summer for the second round of my internship and checked in on that office, I discovered that someone had screwed up or corrupted the backend portion of the database somehow and no one knew how to fix it, so they'd deleted the whole database shortly after I left and gone back to using The Spreadsheet. Because of-fucking-course they did. [link] [comments]  |
| You are subscribed to email updates from Tales From Tech Support. To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
| Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States | |
No comments:
Post a Comment