October 2012 Summaries
6 posts from PagerDuty
Filter
Month:
Year:
Post Summaries
Back to Blog
In a detailed recount of PagerDuty's database transition, the text outlines the complex process of upgrading from MySQL 5.1, with latin1 character encoding, to MySQL 5.5, using the utf8mb4 encoding for full Unicode support. Initially, the company faced challenges with maintaining non-ASCII character support and dealing with performance issues due to MySQL’s limitations and the default latin1 character set. The transition involved addressing MySQL's constraints on index sizes, which restrict the use of utf8mb4 due to its higher byte requirement per character, by configuring the database to use the Barracuda file format and enabling large prefix support. The team utilized master/slave replication to ensure a seamless migration with minimal downtime, enabling character set conversions without data loss. By synchronizing the character set and collation settings between the database and client applications, the migration not only solved character encoding issues but also improved overall system performance. The text concludes with reflections on the successful execution of the migration, emphasizing the importance of addressing legacy system limitations to support modern, global character sets.
Oct 30, 2012
2,555 words in the original blog post.
At Surge 2012 in Baltimore, MD, Andrew, the CTO and co-founder of PagerDuty, delivered a presentation on best practices for responding to system failures, emphasizing the importance of alerting the right person and implementing effective on-call procedures to minimize downtime. The conference attendees were focused on scaling their infrastructure to handle worst-case scenarios and improving system performance. Andrew's talk was recorded by the PagerDuty team, and he was also interviewed by Bryan Berry for "The Food Fight Show" podcast, where he further discussed these topics.
Oct 22, 2012
169 words in the original blog post.
A year after joining PagerDuty, the author faced challenges with the deploy time of their growing Rails application, which had expanded to a distributed and service-oriented architecture. Initially, code deployment to production took about 30 seconds, but it eventually stretched to 6-10 minutes, hampering development speed and enjoyment. To optimize deploy times, the team utilized Capistrano with custom configurations to measure performance bottlenecks. They successfully reduced deploy time to 50 seconds by pruning old git tags, selectively recompiling assets, and using Monit for efficient background job management. Asset-heavy deploys were sped up by avoiding unnecessary recompilations, and background worker restart times were reduced by switching from a synchronous process to a Monit-managed rolling restart. The deploy_test:web_trigger task was also optimized by running it asynchronously. Despite significant improvements, asset compilation remains a challenge, with proposed solutions including pre-minified vendor assets and using continuous integration servers for asynchronous asset building. The overall improvements have facilitated more frequent and efficient deployments.
Oct 18, 2012
1,472 words in the original blog post.
Hiring software engineers is challenging due to the inherent difficulty in assessing whether candidates are truly "hirable," which involves evaluating their skills, experience, and personality. The process can be likened to a machine learning classification problem where the goal is to sort candidates into "hirable" and "non-hirable" categories based on input features gathered from interviews. These features are derived from candidates' responses to a series of questions, which are often reused, leading to potential biases and inaccuracies. The challenge is compounded by the small size of the training set (previous interview data) and the difficulty in accurately labeling candidates as good or bad hires due to limited feedback on false negatives (rejected candidates who would have succeeded) and false positives (hired candidates who underperform). The high cost of false positives makes interviewers cautious, often resulting in conservative hiring decisions. Despite these challenges, the process benefits from ensemble learning during debrief meetings, where multiple interviewers contribute to the final hiring decision by aggregating their individual assessments.
Oct 16, 2012
2,484 words in the original blog post.
In the competitive digital landscape, effective website performance and availability are essential, prompting many businesses to rely on website monitoring services, which vary significantly in quality. Key features of a robust monitoring service include intelligent alerting, which verifies issues across different locations to ensure they are legitimate, and support for multiple browsers to maintain a consistent user experience. Additionally, advanced services offer real user measurements, allowing businesses to understand actual user experiences and make data-driven adjustments, while multiple agent locations are necessary to capture a comprehensive view of global performance. Connie Quach, a Senior Product Manager at Neustar, emphasizes these features while managing Neustar's web performance products and actively engaging the community through the San Diego Web Performance meetup group.
Oct 04, 2012
466 words in the original blog post.
Experimentation and trial and error are key components of learning and improvement, particularly in technical fields, where breaking and fixing things can lead to progress. Historically, such experimentation could lead to untimely alerts during system changes, but with modern tools like PagerDuty, users can now schedule maintenance windows to temporarily silence notifications and focus on resolving issues without disturbance. This feature allows for controlled experimentation, enabling users to script deployments and manage noisy processes without being overwhelmed by non-critical alerts. The flexibility of these maintenance windows supports creativity and innovation by providing the necessary space to troubleshoot and improve systems without constant interruption.
Oct 03, 2012
417 words in the original blog post.