Emmapedia: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
mNo edit summary |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
= There is no such thing as Emmapedia = | = There is no such thing as Emmapedia = | ||
But, this is how I work: | == 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. | * 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. | * 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: | == 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 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 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. | ||
| Line 13: | Line 13: | ||
* 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. | * 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 <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja 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. | * Use your <code>dig</code>, <code>netcat</code>, <code>traceroute</code>, <code>curl</code> and <code>netstat</code> ninja 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 | * Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And if 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 | * 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. | * 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. | * 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. | ||
* Be strict when it comes to security, no matter if you're a security officer or not. If you see anything that's not right, from a password stored in the VCS, to a gaping hole in an application's authentication mechanism, '''''DO SPEAK UP'''''. Someone might hate you for it now, but that's entirely their problem. Someone will thank you for it later on. | |||
== 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, or if 'halfway' proves to be all there is.) | |||
Latest revision as of 13:09, 25 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 if 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.
- Be strict when it comes to security, no matter if you're a security officer or not. If you see anything that's not right, from a password stored in the VCS, to a gaping hole in an application's authentication mechanism, DO SPEAK UP. Someone might hate you for it now, but that's entirely their problem. Someone will thank you for it later on.
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, or if 'halfway' proves to be all there is.)