Bureaucrat, staff, administrator
477
edits
Changes
m
→Observability Squad
* Provided insights from a tester's perspective and liaised with the Westpac Quality Engineering Chapter.
==Observability Squad- Platform Engineer and Splunk Champion==With this team I switched to As a member of the Observability Squad, a more Platform Engineering roleteam tasked with supporting [https://www.splunk.com/ Splunk] and other observability tools like [https://www.dynatrace.com/ Dynatrace], I had the opportunity to learn and became grow in the Westpac role of "'''Splunk Champion'''". We were supporting and growing the Splunk I was encouraged into this role by [https://dirksonline.net/CV/2023%20Isaac%20Carrington%20-%20LinkedIn%20Recommendation.jpg Isaac Carrington]''(Head of Platform Engineering)'' despite lacking prior platform for Westpac internal technology teamsengineering experience. In my role, I have had exposure :* Acquired skills in '''Platform Engineering''' ''(Docker, Linux VM's, Terraform, Bash, HashiCorp Vault)''* Provided '''support''' to internal users to leverage '''Splunk''' ''(Searching, analysis, dashboard creation, PagerDuty integration)''* Managed a distributed instance of Splunk Enterprise ''(Indexers, search heads, forwarders, event collectors, role-based access controls)''* Introduced the Quality Engineering Chapter to use Splunk in previous companies and have truly loved it for analysing data. reporting of results from automation suites Moreover, as the Splunk Champion, I really like wanted to try and find help people see the customerscustomer' experiences come s experience through the databeing collected. When onboarding new systems, I would always ask guided users through a series of questions aimed at maximizing the teams we were supporting value extracted from Splunk data, focusing on their Splunk onboarding journey three things: # Are you logging how well your monitoring '''product/service/feature is working? eg transactions per hour# Are you catching all the errors performance''', '''error detection''', and warnings to know when the product/service/feature is doing something bad# When you observe an error/warning are you recording good '''quality information that truly helps devOps understand the ''' being recording for '''efficient issueresolution'''. Ultimately, and expedites the remediation goal of the issue? The latter I find particularly important because in the end the objective observability is to minimise the risk of major swiftly remediate critical issues by knowing about detecting them quickly, [[understanding their impact, and]] also being able to solve resolving them quicklypromptly. Timely & good Therefore, '''timely and quality information is remains paramount''' in achieving this objective.
==D365 KiwiSaver Squad==