Emmapedia: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 18: | Line 18: | ||
* Read faster. The internet is a big place. Google will return a lot of rubbish. You'll need to be able to skip that in seconds instead of minutes. | * Read faster. The internet is a big place. Google will return a lot of rubbish. You'll need to be able to skip that in seconds instead of minutes. | ||
== | == You already knew that? == | ||
Good! It took me a while to come up with this list, and it's not even halfway. (Note to self: I think I can leave this in for the foreseeable future, even if the list becomes ten times as long.) | |||
Revision as of 06:52, 16 January 2023
There is no such thing as Emmapedia
But, this is how I work:
- Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your IT job, you haven't done enough automation.
- Be honest about what you know, and what you don't know. People appreciate the information that something isn't a fact but a guess. And if it's an educated guess and you were right, they'll be happy you pointed them in the right direction anyway.
Then:
- Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
- Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
- Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
- Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
- Look where the application is logging to. Read the logs. If there are no logs, the application just might not be able to run at all. Increase the log level if necessary.
- Use your
dig,netcat,traceroute,curlandnetstatninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows. - Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And it it's a web application in Azure, these things are probably in the properties.
- Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
- Still no luck? Use your Google-fu. There's very little that cannot be found on ServerFault or StackOverflow.
- Read faster. The internet is a big place. Google will return a lot of rubbish. You'll need to be able to skip that in seconds instead of minutes.
You already knew that?
Good! It took me a while to come up with this list, and it's not even halfway. (Note to self: I think I can leave this in for the foreseeable future, even if the list becomes ten times as long.)