Vertu's Digital Transformation
•Download as PPTX, PDF•
2 likes•655 views
Find out how Vertu has transformed on three fronts: Cloud, DevOps and Data over the last 5 years and in particular how we make use of Splunk. This talk was given at Gartner Catalyst 2015 in London, as well as at IP Expo Europe 2015.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Vertu's Digital Transformation
Similar to Vertu's Digital Transformation (20)
Recently uploaded
Recently uploaded (20)
Vertu's Digital Transformation
- 1. Copyright © 2015 Splunk Inc. Rob Charlton Cloud DevOps Architect, Vertu Vertu’s digital transformation
- 2. Agenda 1. About Vertu 2. Vertu’s Digital Transformation • Cloud • DevOps • Data & IoT
- 3. About Vertu Corporation British manufacturer and retailer of handmade luxury phones
- 4. About Vertu Corporation Built by a single craftsman
- 5. About Vertu Corporation Exclusive services
- 6. Vertu Timeline 1998 2002 Signature – First phone Founded by Nokia 2010 First Smartphone 2012 Private Equity 2013 Vertu Ti (Android) 2014 Vertu Aster 2015 Signature Touch
- 7. Vertu’s Digital Transformation Cloud Ops culture Data and IoT
- 8. Vertu’s Digital Transformation Cloud On-premises & managed IT Ops culture Data and IoT
- 9. Vertu’s Digital Transformation Cloud On-premises & managed IT Ops culture Data and IoT
- 10. Vertu’s Digital Transformation Cloud On-premises & managed IT Ops culture Data and IoT No Ops function
- 11. Vertu’s Digital Transformation Cloud On-premises & managed IT Ops culture Data and IoT On the path to DevOpsNo Ops function
- 12. Vertu’s Digital Transformation Cloud On-premises & managed IT Ops culture Data and IoT On the path to DevOpsNo Ops function
- 13. Vertu’s Digital Transformation Cloud On-premises & managed IT Ops culture Data and IoT On the path to DevOpsNo Ops function
- 14. Transformation: Cloud Back in 2011 we worked with multiple managed service providers in multiple data centres. We started the process of automation early though, adopting Puppet even at this stage. 2011
- 15. Transformation: Cloud 2012 In 2012 we consolidated and migrated everything to a single VMware private cloud. We used automation and built tools to ensure customers didn’t even notice.
- 16. Transformation: Cloud 2015 import boto ec2 = boto.connect_ec2() reservation = ec2.run_instances( image_id='ami-bb709dd2', key_name='ec2-sample-key') In 2015 we completed a full migration from VMware to Amazon Web Services – using EC2, VPC, RDS, ELB and allowing us access to all their features from Python!
- 17. Transformation: Culture & DevOps
- 18. Transformation: Culture & DevOps
- 19. Transformation: Culture & DevOps http://wp.me/p6k7pa-l
- 20. Transformation: Culture & DevOps • We’re climbing up the pyramid: http://wp.me/p6k7pa-l
- 21. Transformation: Culture & DevOps • We’re climbing up the pyramid: • IaaS – Amazon! http://wp.me/p6k7pa-l
- 22. Transformation: Culture & DevOps • We’re climbing up the pyramid: • IaaS – Amazon! • Repeatability – Ansible! http://wp.me/p6k7pa-l
- 23. Transformation: Culture & DevOps • We’re climbing up the pyramid: • IaaS – Amazon! • Repeatability – Ansible! • Tooling – Jenkins, Packer, Consul.io http://wp.me/p6k7pa-l
- 24. Transformation: Data & IoT - challenge • How to become more data led when productizing a phone? • Hundreds of mobile devices under test with individuals • Who has tested what, for how long? • How many phone / modem / system crashes? • Can we launch?
- 25. How to make an Android mobile phone
- 26. How to make an Android mobile phone Drivers Qualcomm provide a layer of drivers to work with their hardware. Power Management, Camera, Modem, Security, Sensors etc.
- 27. How to make an Android mobile phone Drivers Linux The Linux layer consists of the kernel as well as boot code
- 28. How to make an Android mobile phone Drivers Linux “Android” - AOSP Google’s Android actually only makes up this part – the “Android Open Source Project” and “Google Mobile Services”
- 29. How to make an Android mobile phone Drivers Linux “Android” - AOSP Apps Vertu adds its own Apps, to support the services which come with our phones. Other Apps from the play store form this layer too.
- 30. How to make an Android mobile phone Drivers Linux “Android” - AOSP Apps System Integration Partner As with most Android phone manufacturers, we use a System Integration Partner to help us make all these layers of software work optimally together. This involves tuning settings, making custom changes and applying thousands of patches.
- 31. How to make an Android mobile phone Drivers Linux “Android” - AOSP Apps System Integration Partner Tackling quality issues in this layer is well supported and understood. Splunk’s MINT can help here! App providers will fix their own apps.
- 32. How to make an Android mobile phone Drivers Linux “Android” - AOSP Apps System Integration Partner This is where the big challenge lies! There is a lot of software here, with many parties working on it. If it goes wrong it means your phone resets, runs out of battery, misses calls, takes fuzzy photos etc. The phone can reset silently too!
- 33. Transformation: Data & IoT – our solution
- 34. Transformation: Data & IoT – our solution Metrics collation agent During the productization phase, we run an agent on our phones to collect metrics: uptime, crashes, battery stats and other product health information
- 35. Transformation: Data & IoT – our solution Metrics collation agent The phones regularly upload metrics to a web service running in our Amazon cloud
- 36. Transformation: Data & IoT – our solution Metrics collation agent A Splunk Forwarder feeds the data into our Splunk Enterprise cluster
- 37. Transformation: Data & IoT – our solution Metrics collation agent Splunk will send out email alerts to our crash analysis team whenever a phone reset is detected
- 38. Transformation: Data & IoT – our solution Metrics collation agent The project management team will use Splunk dashboards to assess the state of the software
- 39. Transformation: Data & IoT – our solution Metrics collation agent
- 40. Crash Alert!
- 41. Crash Alert! Cause of the crash
- 42. Crash Alert! Cause of the crash Which tester has the phone
- 43. Crash Alert! Cause of the crash Which tester has the phone When the crash happened
- 44. Crash Alert! Cause of the crash Which tester has the phone When the crash happened What phone software version
- 45. MTBF Dashboard
- 46. MTBF Dashboard
- 47. MTBF Dashboard
- 48. MTBF Dashboard
- 51. The future • Our Digital Transformation is ongoing:
- 52. The future • Our Digital Transformation is ongoing:
- 53. The future • Our Digital Transformation is ongoing: Using AWS resources in a smart way – auto scaling up and down, RDS and DynamoDB
- 54. The future • Our Digital Transformation is ongoing: Climb that pyramid! Employ Jenkins, Packer, Consul.io to build a world class continuous delivery system
- 55. The future • Our Digital Transformation is ongoing: Continue to improve our use of Splunk and data – real-time searches, new features in Splunk 6.3, more dashboards. JIRA integration
- 56. Ask me about Digital Transformation… @charltones charltones@gmail.com Questions?
- 57. Thank you
Editor's Notes
- I work for Vertu as a Cloud DevOps Architect. I’m going to explain a little bit about Vertu and what we do, then tell you about the Digital Transformation Vertu has undergone over the last 5 years on three fronts: Cloud, DevOps and Data.
- Vertu is a British manufacturer and retailer of handmade luxury mobile phones. The phones are made on site in Hampshire using luxury materials like titanium, hand-stitched leather and sapphire crystal.
- Each one is built and signed by a single craftsman. We sell phones globally in 600 stores and 70 of our own boutiques.
- The phones come with a range of exclusive services such as our Concierge service that will put you in touch with a 24x7 lifestyle manager that can arrange whatever you need: flights, opera tickets, a table at an exclusive restaurant that’s fully booked.
- Founded in 1998 as a subsidiary of Nokia, Vertu made its first phone, the Signature in 2002 – the latest version of this is still sold today! We made our first luxury smartphone in 2010, before being acquired by a Private Equity Firm in 2012. Since then we’ve focussed on making Luxury Android Smartphones, starting in 2013. Our most recent phone, the Signature Touch, launched just last week. With Android 5.1 Lollipop running on a Qualcomm Snapdragon 810 octa-core processor, 128 GB of internal & micro SD storage, 21MP camera and 5.2” 1080p display it’s cutting edge in technology as well as in craftsmanship.
- Over the last 5 years Vertu has undergone a Digital Transformation on three main fronts: In infrastructure we’ve migrated from a collection of on premises and managed IT data centres to running all of our services in Amazon AWS. In ops we’ve gone from having no ops function at all, to climbing the path towards DevOps – Culture, Automation, Lean, Metrics, Sharing In data we’ve gone from using gut feel, instinct and experience alone to combining that with a data led approach using Splunk Enterprise.
- Over the last 5 years Vertu has undergone a Digital Transformation on three main fronts: In infrastructure we’ve migrated from a collection of on premises and managed IT data centres to running all of our services in Amazon AWS. In ops we’ve gone from having no ops function at all, to climbing the path towards DevOps – Culture, Automation, Lean, Metrics, Sharing In data we’ve gone from using gut feel, instinct and experience alone to combining that with a data led approach using Splunk Enterprise.
- Over the last 5 years Vertu has undergone a Digital Transformation on three main fronts: In infrastructure we’ve migrated from a collection of on premises and managed IT data centres to running all of our services in Amazon AWS. In ops we’ve gone from having no ops function at all, to climbing the path towards DevOps – Culture, Automation, Lean, Metrics, Sharing In data we’ve gone from using gut feel, instinct and experience alone to combining that with a data led approach using Splunk Enterprise.
- Over the last 5 years Vertu has undergone a Digital Transformation on three main fronts: In infrastructure we’ve migrated from a collection of on premises and managed IT data centres to running all of our services in Amazon AWS. In ops we’ve gone from having no ops function at all, to climbing the path towards DevOps – Culture, Automation, Lean, Metrics, Sharing In data we’ve gone from using gut feel, instinct and experience alone to combining that with a data led approach using Splunk Enterprise.
- Over the last 5 years Vertu has undergone a Digital Transformation on three main fronts: In infrastructure we’ve migrated from a collection of on premises and managed IT data centres to running all of our services in Amazon AWS. In ops we’ve gone from having no ops function at all, to climbing the path towards DevOps – Culture, Automation, Lean, Metrics, Sharing In data we’ve gone from using gut feel, instinct and experience alone to combining that with a data led approach using Splunk Enterprise.
- Over the last 5 years Vertu has undergone a Digital Transformation on three main fronts: In infrastructure we’ve migrated from a collection of on premises and managed IT data centres to running all of our services in Amazon AWS. In ops we’ve gone from having no ops function at all, to climbing the path towards DevOps – Culture, Automation, Lean, Metrics, Sharing In data we’ve gone from using gut feel, instinct and experience alone to combining that with a data led approach using Splunk Enterprise.
- Over the last 5 years Vertu has undergone a Digital Transformation on three main fronts: In infrastructure we’ve migrated from a collection of on premises and managed IT data centres to running all of our services in Amazon AWS. In ops we’ve gone from having no ops function at all, to climbing the path towards DevOps – Culture, Automation, Lean, Metrics, Sharing In data we’ve gone from using gut feel, instinct and experience alone to combining that with a data led approach using Splunk Enterprise.
- Our cloud transformation started from a fairly common position – a heterogeneous collection of different data centres and managed services which was complex, expensive and slow to change. We looked to the future though and started introducing automation early using a tool called Puppet, as we knew where we wanted to go. In 2012, triggered by the need to separate our IT systems from Nokia, we consolidated all of the data centres together and migrated them to a VMware private cloud. We build custom monitoring and migration tools and employed automation via Puppet to ensure the process was as seamless as possible. Our customers and most of Vertu didn’t even notice we had migrated – which is exactly what you want from a migration! Early in 2015, we migrated again. Our private cloud hardware was reaching end of life and needed replacing. We didn’t have a way to scale up for experimentation or scale down to reduce costs. So we looked to the future once again and moved everything over to Amazon AWS. We evaluated cloud providers and chose Amazon because of the breadth of solutions in their catalog and their pace of innovation. We can now stop and start machines, create networks and loadbalancers all from Python, as this code snippet shows.
- Our cloud transformation started from a fairly common position – a heterogeneous collection of different data centres and managed services which was complex, expensive and slow to change. We looked to the future though and started introducing automation early using a tool called Puppet, as we knew where we wanted to go. In 2012, triggered by the need to separate our IT systems from Nokia, we consolidated all of the data centres together and migrated them to a VMware private cloud. We build custom monitoring and migration tools and employed automation via Puppet to ensure the process was as seamless as possible. Our customers and most of Vertu didn’t even notice we had migrated – which is exactly what you want from a migration! Early in 2015, we migrated again. Our private cloud hardware was reaching end of life and needed replacing. We didn’t have a way to scale up for experimentation or scale down to reduce costs. So we looked to the future once again and moved everything over to Amazon AWS. We evaluated cloud providers and chose Amazon because of the breadth of solutions in their catalog and their pace of innovation. We can now stop and start machines, create networks and loadbalancers all from Python, as this code snippet shows.
- Our cloud transformation started from a fairly common position – a heterogeneous collection of different data centres and managed services which was complex, expensive and slow to change. We looked to the future though and started introducing automation early using a tool called Puppet, as we knew where we wanted to go. In 2012, triggered by the need to separate our IT systems from Nokia, we consolidated all of the data centres together and migrated them to a VMware private cloud. We build custom monitoring and migration tools and employed automation via Puppet to ensure the process was as seamless as possible. Our customers and most of Vertu didn’t even notice we had migrated – which is exactly what you want from a migration! Early in 2015, we migrated again. Our private cloud hardware was reaching end of life and needed replacing. We didn’t have a way to scale up for experimentation or scale down to reduce costs. So we looked to the future once again and moved everything over to Amazon AWS. We evaluated cloud providers and chose Amazon because of the breadth of solutions in their catalog and their pace of innovation. We can now stop and start machines, create networks and loadbalancers all from Python, as this code snippet shows.
- Our second transformation axis involved our approach to IT operations. I was reading an excellent blog post last week by Space Ape games which described their journey to DevOps as climbing a ‘Hierarchy of DevOps needs’. We’re not as far as they are, but our journey has been similar. It all starts with IaaS, which we’ve now adopted with Amazon. The next stage is to be able to deploy your infrastructure in a repeatable manner. We first used Puppet for this but last year moved to a newer tool called Ansible. All our infrastructure is deployed using Ansible, and all the Ansible code is versioned in Git. Our infrastructure is code. We’re just starting to ascend to the next level which Space Ape suggests is using tools that deploy and manage your infrastructure for you. We’re using Jenkins right now, and are evaluating Packer and Consul.io which we intend to combine to lead to a world class Continuous Delivery solution.
- Our second transformation axis involved our approach to IT operations. I was reading an excellent blog post last week by Space Ape games which described their journey to DevOps as climbing a ‘Hierarchy of DevOps needs’. We’re not as far as they are, but our journey has been similar. It all starts with IaaS, which we’ve now adopted with Amazon. The next stage is to be able to deploy your infrastructure in a repeatable manner. We first used Puppet for this but last year moved to a newer tool called Ansible. All our infrastructure is deployed using Ansible, and all the Ansible code is versioned in Git. Our infrastructure is code. We’re just starting to ascend to the next level which Space Ape suggests is using tools that deploy and manage your infrastructure for you. We’re using Jenkins right now, and are evaluating Packer and Consul.io which we intend to combine to lead to a world class Continuous Delivery solution.
- Our second transformation axis involved our approach to IT operations. I was reading an excellent blog post last week by Space Ape games which described their journey to DevOps as climbing a ‘Hierarchy of DevOps needs’. We’re not as far as they are, but our journey has been similar. It all starts with IaaS, which we’ve now adopted with Amazon. The next stage is to be able to deploy your infrastructure in a repeatable manner. We first used Puppet for this but last year moved to a newer tool called Ansible. All our infrastructure is deployed using Ansible, and all the Ansible code is versioned in Git. Our infrastructure is code. We’re just starting to ascend to the next level which Space Ape suggests is using tools that deploy and manage your infrastructure for you. We’re using Jenkins right now, and are evaluating Packer and Consul.io which we intend to combine to lead to a world class Continuous Delivery solution.
- Our second transformation axis involved our approach to IT operations. I was reading an excellent blog post last week by Space Ape games which described their journey to DevOps as climbing a ‘Hierarchy of DevOps needs’. We’re not as far as they are, but our journey has been similar. It all starts with IaaS, which we’ve now adopted with Amazon. The next stage is to be able to deploy your infrastructure in a repeatable manner. We first used Puppet for this but last year moved to a newer tool called Ansible. All our infrastructure is deployed using Ansible, and all the Ansible code is versioned in Git. Our infrastructure is code. We’re just starting to ascend to the next level which Space Ape suggests is using tools that deploy and manage your infrastructure for you. We’re using Jenkins right now, and are evaluating Packer and Consul.io which we intend to combine to lead to a world class Continuous Delivery solution.
- Our second transformation axis involved our approach to IT operations. I was reading an excellent blog post last week by Space Ape games which described their journey to DevOps as climbing a ‘Hierarchy of DevOps needs’. We’re not as far as they are, but our journey has been similar. It all starts with IaaS, which we’ve now adopted with Amazon. The next stage is to be able to deploy your infrastructure in a repeatable manner. We first used Puppet for this but last year moved to a newer tool called Ansible. All our infrastructure is deployed using Ansible, and all the Ansible code is versioned in Git. Our infrastructure is code. We’re just starting to ascend to the next level which Space Ape suggests is using tools that deploy and manage your infrastructure for you. We’re using Jenkins right now, and are evaluating Packer and Consul.io which we intend to combine to lead to a world class Continuous Delivery solution.
- Our second transformation axis involved our approach to IT operations. I was reading an excellent blog post last week by Space Ape games which described their journey to DevOps as climbing a ‘Hierarchy of DevOps needs’. We’re not as far as they are, but our journey has been similar. It all starts with IaaS, which we’ve now adopted with Amazon. The next stage is to be able to deploy your infrastructure in a repeatable manner. We first used Puppet for this but last year moved to a newer tool called Ansible. All our infrastructure is deployed using Ansible, and all the Ansible code is versioned in Git. Our infrastructure is code. We’re just starting to ascend to the next level which Space Ape suggests is using tools that deploy and manage your infrastructure for you. We’re using Jenkins right now, and are evaluating Packer and Consul.io which we intend to combine to lead to a world class Continuous Delivery solution.
- Our second transformation axis involved our approach to IT operations. I was reading an excellent blog post last week by Space Ape games which described their journey to DevOps as climbing a ‘Hierarchy of DevOps needs’. We’re not as far as they are, but our journey has been similar. It all starts with IaaS, which we’ve now adopted with Amazon. The next stage is to be able to deploy your infrastructure in a repeatable manner. We first used Puppet for this but last year moved to a newer tool called Ansible. All our infrastructure is deployed using Ansible, and all the Ansible code is versioned in Git. Our infrastructure is code. We’re just starting to ascend to the next level which Space Ape suggests is using tools that deploy and manage your infrastructure for you. We’re using Jenkins right now, and are evaluating Packer and Consul.io which we intend to combine to lead to a world class Continuous Delivery solution.
- The 3rd transformation we’ve undergone was in data. We make mobile phones and we have very discerning customers. When we are productizing a phone we typically have hundreds of phones under test by individuals in the UK and around the world. The programme manager responsible for the phone has some very basic questions: Who has tested what, and for how long? How many crashes or errors have there been? These two questions give an industry standard figure called Mean Time Between Failures (MTBF) which you expect to reach several hundred hours for a reliable phone. Ultimately the big question is: Can we launch? So why is this a challenge?
- To answer that, I need to make a small digression to explain what is involved in making an Android mobile phone. It all starts with the silicon vendor – as well as supplying the chipset, Qualcomm provide use with a whole package of drivers to support all the different devices in the phone: camera, sensors, security subsystem, modem, power management etc. Next we have the linux layer – this is the same kernel that’s in a linux server – as well as the boot system. Then we have Google’s contribution – this is the bit of the Android phone that is actually Android. The Android Open Source Project (AOSP) contains most of the Android framework and some of the applications. The rest you may be familiar with: Play Store, Chrome, Gmail etc. makes up “Google Mobile Services” (GMS) and this is the closed-source portion of Android. Finally at the top we have Apps. Vertu adds some of our own apps in here: client applications for our suite of services like Concierge, but this layer also includes the apps you might download from the Play store, like Facebook, Twitter, LinkedIn and Angry Birds. There’s a lot of work to bring all these layers together into a high quality phone. Like many phone manufacturers we use a System Integration Partner to help us here. They make changes at all the levels – tuning, configuring and applying thousands of patches. So where do the quality issues occur? Well, at the Apps layer it is very well understood. There are lots of tools to help and Splunk have an offering called MINT specifically to tackle this. App vendors will of course be fixing problems in their own applications, so if Facebook crashes then Facebook will address that. But these lower layers are the big challenge for us and other manufacturers. There is a _lot_ of software here and issues at this level will do more than just make an App exit. The phone can reboot (sometimes silently, in your bag), it could drop calls or lose signal, take fuzzy photos or run out of battery too quickly. So, how did we tackle this?
- To answer that, I need to make a small digression to explain what is involved in making an Android mobile phone. It all starts with the silicon vendor – as well as supplying the chipset, Qualcomm provide use with a whole package of drivers to support all the different devices in the phone: camera, sensors, security subsystem, modem, power management etc. Next we have the linux layer – this is the same kernel that’s in a linux server – as well as the boot system. Then we have Google’s contribution – this is the bit of the Android phone that is actually Android. The Android Open Source Project (AOSP) contains most of the Android framework and some of the applications. The rest you may be familiar with: Play Store, Chrome, Gmail etc. makes up “Google Mobile Services” (GMS) and this is the closed-source portion of Android. Finally at the top we have Apps. Vertu adds some of our own apps in here: client applications for our suite of services like Concierge, but this layer also includes the apps you might download from the Play store, like Facebook, Twitter, LinkedIn and Angry Birds. There’s a lot of work to bring all these layers together into a high quality phone. Like many phone manufacturers we use a System Integration Partner to help us here. They make changes at all the levels – tuning, configuring and applying thousands of patches. So where do the quality issues occur? Well, at the Apps layer it is very well understood. There are lots of tools to help and Splunk have an offering called MINT specifically to tackle this. App vendors will of course be fixing problems in their own applications, so if Facebook crashes then Facebook will address that. But these lower layers are the big challenge for us and other manufacturers. There is a _lot_ of software here and issues at this level will do more than just make an App exit. The phone can reboot (sometimes silently, in your bag), it could drop calls or lose signal, take fuzzy photos or run out of battery too quickly. So, how did we tackle this?
- To answer that, I need to make a small digression to explain what is involved in making an Android mobile phone. It all starts with the silicon vendor – as well as supplying the chipset, Qualcomm provide use with a whole package of drivers to support all the different devices in the phone: camera, sensors, security subsystem, modem, power management etc. Next we have the linux layer – this is the same kernel that’s in a linux server – as well as the boot system. Then we have Google’s contribution – this is the bit of the Android phone that is actually Android. The Android Open Source Project (AOSP) contains most of the Android framework and some of the applications. The rest you may be familiar with: Play Store, Chrome, Gmail etc. makes up “Google Mobile Services” (GMS) and this is the closed-source portion of Android. Finally at the top we have Apps. Vertu adds some of our own apps in here: client applications for our suite of services like Concierge, but this layer also includes the apps you might download from the Play store, like Facebook, Twitter, LinkedIn and Angry Birds. There’s a lot of work to bring all these layers together into a high quality phone. Like many phone manufacturers we use a System Integration Partner to help us here. They make changes at all the levels – tuning, configuring and applying thousands of patches. So where do the quality issues occur? Well, at the Apps layer it is very well understood. There are lots of tools to help and Splunk have an offering called MINT specifically to tackle this. App vendors will of course be fixing problems in their own applications, so if Facebook crashes then Facebook will address that. But these lower layers are the big challenge for us and other manufacturers. There is a _lot_ of software here and issues at this level will do more than just make an App exit. The phone can reboot (sometimes silently, in your bag), it could drop calls or lose signal, take fuzzy photos or run out of battery too quickly. So, how did we tackle this?
- To answer that, I need to make a small digression to explain what is involved in making an Android mobile phone. It all starts with the silicon vendor – as well as supplying the chipset, Qualcomm provide use with a whole package of drivers to support all the different devices in the phone: camera, sensors, security subsystem, modem, power management etc. Next we have the linux layer – this is the same kernel that’s in a linux server – as well as the boot system. Then we have Google’s contribution – this is the bit of the Android phone that is actually Android. The Android Open Source Project (AOSP) contains most of the Android framework and some of the applications. The rest you may be familiar with: Play Store, Chrome, Gmail etc. makes up “Google Mobile Services” (GMS) and this is the closed-source portion of Android. Finally at the top we have Apps. Vertu adds some of our own apps in here: client applications for our suite of services like Concierge, but this layer also includes the apps you might download from the Play store, like Facebook, Twitter, LinkedIn and Angry Birds. There’s a lot of work to bring all these layers together into a high quality phone. Like many phone manufacturers we use a System Integration Partner to help us here. They make changes at all the levels – tuning, configuring and applying thousands of patches. So where do the quality issues occur? Well, at the Apps layer it is very well understood. There are lots of tools to help and Splunk have an offering called MINT specifically to tackle this. App vendors will of course be fixing problems in their own applications, so if Facebook crashes then Facebook will address that. But these lower layers are the big challenge for us and other manufacturers. There is a _lot_ of software here and issues at this level will do more than just make an App exit. The phone can reboot (sometimes silently, in your bag), it could drop calls or lose signal, take fuzzy photos or run out of battery too quickly. So, how did we tackle this?
- To answer that, I need to make a small digression to explain what is involved in making an Android mobile phone. It all starts with the silicon vendor – as well as supplying the chipset, Qualcomm provide use with a whole package of drivers to support all the different devices in the phone: camera, sensors, security subsystem, modem, power management etc. Next we have the linux layer – this is the same kernel that’s in a linux server – as well as the boot system. Then we have Google’s contribution – this is the bit of the Android phone that is actually Android. The Android Open Source Project (AOSP) contains most of the Android framework and some of the applications. The rest you may be familiar with: Play Store, Chrome, Gmail etc. makes up “Google Mobile Services” (GMS) and this is the closed-source portion of Android. Finally at the top we have Apps. Vertu adds some of our own apps in here: client applications for our suite of services like Concierge, but this layer also includes the apps you might download from the Play store, like Facebook, Twitter, LinkedIn and Angry Birds. There’s a lot of work to bring all these layers together into a high quality phone. Like many phone manufacturers we use a System Integration Partner to help us here. They make changes at all the levels – tuning, configuring and applying thousands of patches. So where do the quality issues occur? Well, at the Apps layer it is very well understood. There are lots of tools to help and Splunk have an offering called MINT specifically to tackle this. App vendors will of course be fixing problems in their own applications, so if Facebook crashes then Facebook will address that. But these lower layers are the big challenge for us and other manufacturers. There is a _lot_ of software here and issues at this level will do more than just make an App exit. The phone can reboot (sometimes silently, in your bag), it could drop calls or lose signal, take fuzzy photos or run out of battery too quickly. So, how did we tackle this?
- To answer that, I need to make a small digression to explain what is involved in making an Android mobile phone. It all starts with the silicon vendor – as well as supplying the chipset, Qualcomm provide use with a whole package of drivers to support all the different devices in the phone: camera, sensors, security subsystem, modem, power management etc. Next we have the linux layer – this is the same kernel that’s in a linux server – as well as the boot system. Then we have Google’s contribution – this is the bit of the Android phone that is actually Android. The Android Open Source Project (AOSP) contains most of the Android framework and some of the applications. The rest you may be familiar with: Play Store, Chrome, Gmail etc. makes up “Google Mobile Services” (GMS) and this is the closed-source portion of Android. Finally at the top we have Apps. Vertu adds some of our own apps in here: client applications for our suite of services like Concierge, but this layer also includes the apps you might download from the Play store, like Facebook, Twitter, LinkedIn and Angry Birds. There’s a lot of work to bring all these layers together into a high quality phone. Like many phone manufacturers we use a System Integration Partner to help us here. They make changes at all the levels – tuning, configuring and applying thousands of patches. So where do the quality issues occur? Well, at the Apps layer it is very well understood. There are lots of tools to help and Splunk have an offering called MINT specifically to tackle this. App vendors will of course be fixing problems in their own applications, so if Facebook crashes then Facebook will address that. But these lower layers are the big challenge for us and other manufacturers. There is a _lot_ of software here and issues at this level will do more than just make an App exit. The phone can reboot (sometimes silently, in your bag), it could drop calls or lose signal, take fuzzy photos or run out of battery too quickly. So, how did we tackle this?
- To answer that, I need to make a small digression to explain what is involved in making an Android mobile phone. It all starts with the silicon vendor – as well as supplying the chipset, Qualcomm provide use with a whole package of drivers to support all the different devices in the phone: camera, sensors, security subsystem, modem, power management etc. Next we have the linux layer – this is the same kernel that’s in a linux server – as well as the boot system. Then we have Google’s contribution – this is the bit of the Android phone that is actually Android. The Android Open Source Project (AOSP) contains most of the Android framework and some of the applications. The rest you may be familiar with: Play Store, Chrome, Gmail etc. makes up “Google Mobile Services” (GMS) and this is the closed-source portion of Android. Finally at the top we have Apps. Vertu adds some of our own apps in here: client applications for our suite of services like Concierge, but this layer also includes the apps you might download from the Play store, like Facebook, Twitter, LinkedIn and Angry Birds. There’s a lot of work to bring all these layers together into a high quality phone. Like many phone manufacturers we use a System Integration Partner to help us here. They make changes at all the levels – tuning, configuring and applying thousands of patches. So where do the quality issues occur? Well, at the Apps layer it is very well understood. There are lots of tools to help and Splunk have an offering called MINT specifically to tackle this. App vendors will of course be fixing problems in their own applications, so if Facebook crashes then Facebook will address that. But these lower layers are the big challenge for us and other manufacturers. There is a _lot_ of software here and issues at this level will do more than just make an App exit. The phone can reboot (sometimes silently, in your bag), it could drop calls or lose signal, take fuzzy photos or run out of battery too quickly. So, how did we tackle this?
- To answer that, I need to make a small digression to explain what is involved in making an Android mobile phone. It all starts with the silicon vendor – as well as supplying the chipset, Qualcomm provide use with a whole package of drivers to support all the different devices in the phone: camera, sensors, security subsystem, modem, power management etc. Next we have the linux layer – this is the same kernel that’s in a linux server – as well as the boot system. Then we have Google’s contribution – this is the bit of the Android phone that is actually Android. The Android Open Source Project (AOSP) contains most of the Android framework and some of the applications. The rest you may be familiar with: Play Store, Chrome, Gmail etc. makes up “Google Mobile Services” (GMS) and this is the closed-source portion of Android. Finally at the top we have Apps. Vertu adds some of our own apps in here: client applications for our suite of services like Concierge, but this layer also includes the apps you might download from the Play store, like Facebook, Twitter, LinkedIn and Angry Birds. There’s a lot of work to bring all these layers together into a high quality phone. Like many phone manufacturers we use a System Integration Partner to help us here. They make changes at all the levels – tuning, configuring and applying thousands of patches. So where do the quality issues occur? Well, at the Apps layer it is very well understood. There are lots of tools to help and Splunk have an offering called MINT specifically to tackle this. App vendors will of course be fixing problems in their own applications, so if Facebook crashes then Facebook will address that. But these lower layers are the big challenge for us and other manufacturers. There is a _lot_ of software here and issues at this level will do more than just make an App exit. The phone can reboot (sometimes silently, in your bag), it could drop calls or lose signal, take fuzzy photos or run out of battery too quickly. So, how did we tackle this?
- This is our solution. During the phone productization phase, when we are developing and testing and fixing the phone, we run a metrics collection agent on all the handsets. This will collect an array of different product health information: how long the phone has been on, battery level, crash details etc. Periodically, the agent will upload these metrics to a web service running in our Amazon cloud. A Splunk Forwarder feeds the metrics into our Splunk Enterprise Cluster where they can be analysed. We use Splunk Alerts to send out emails when crashes are detected. These go to our crash analysis team who can find the problematic phone and ask the tester what they were doing, take logs etc. The project management team responsible for the phone will use Splunk Dashboards to assess the state of the software. I’ve got some examples to show you…
- This is our solution. During the phone productization phase, when we are developing and testing and fixing the phone, we run a metrics collection agent on all the handsets. This will collect an array of different product health information: how long the phone has been on, battery level, crash details etc. Periodically, the agent will upload these metrics to a web service running in our Amazon cloud. A Splunk Forwarder feeds the metrics into our Splunk Enterprise Cluster where they can be analysed. We use Splunk Alerts to send out emails when crashes are detected. These go to our crash analysis team who can find the problematic phone and ask the tester what they were doing, take logs etc. The project management team responsible for the phone will use Splunk Dashboards to assess the state of the software. I’ve got some examples to show you…
- This is our solution. During the phone productization phase, when we are developing and testing and fixing the phone, we run a metrics collection agent on all the handsets. This will collect an array of different product health information: how long the phone has been on, battery level, crash details etc. Periodically, the agent will upload these metrics to a web service running in our Amazon cloud. A Splunk Forwarder feeds the metrics into our Splunk Enterprise Cluster where they can be analysed. We use Splunk Alerts to send out emails when crashes are detected. These go to our crash analysis team who can find the problematic phone and ask the tester what they were doing, take logs etc. The project management team responsible for the phone will use Splunk Dashboards to assess the state of the software. I’ve got some examples to show you…
- This is our solution. During the phone productization phase, when we are developing and testing and fixing the phone, we run a metrics collection agent on all the handsets. This will collect an array of different product health information: how long the phone has been on, battery level, crash details etc. Periodically, the agent will upload these metrics to a web service running in our Amazon cloud. A Splunk Forwarder feeds the metrics into our Splunk Enterprise Cluster where they can be analysed. We use Splunk Alerts to send out emails when crashes are detected. These go to our crash analysis team who can find the problematic phone and ask the tester what they were doing, take logs etc. The project management team responsible for the phone will use Splunk Dashboards to assess the state of the software. I’ve got some examples to show you…
- This is our solution. During the phone productization phase, when we are developing and testing and fixing the phone, we run a metrics collection agent on all the handsets. This will collect an array of different product health information: how long the phone has been on, battery level, crash details etc. Periodically, the agent will upload these metrics to a web service running in our Amazon cloud. A Splunk Forwarder feeds the metrics into our Splunk Enterprise Cluster where they can be analysed. We use Splunk Alerts to send out emails when crashes are detected. These go to our crash analysis team who can find the problematic phone and ask the tester what they were doing, take logs etc. The project management team responsible for the phone will use Splunk Dashboards to assess the state of the software. I’ve got some examples to show you…
- This is our solution. During the phone productization phase, when we are developing and testing and fixing the phone, we run a metrics collection agent on all the handsets. This will collect an array of different product health information: how long the phone has been on, battery level, crash details etc. Periodically, the agent will upload these metrics to a web service running in our Amazon cloud. A Splunk Forwarder feeds the metrics into our Splunk Enterprise Cluster where they can be analysed. We use Splunk Alerts to send out emails when crashes are detected. These go to our crash analysis team who can find the problematic phone and ask the tester what they were doing, take logs etc. The project management team responsible for the phone will use Splunk Dashboards to assess the state of the software. I’ve got some examples to show you…
- This is our solution. During the phone productization phase, when we are developing and testing and fixing the phone, we run a metrics collection agent on all the handsets. This will collect an array of different product health information: how long the phone has been on, battery level, crash details etc. Periodically, the agent will upload these metrics to a web service running in our Amazon cloud. A Splunk Forwarder feeds the metrics into our Splunk Enterprise Cluster where they can be analysed. We use Splunk Alerts to send out emails when crashes are detected. These go to our crash analysis team who can find the problematic phone and ask the tester what they were doing, take logs etc. The project management team responsible for the phone will use Splunk Dashboards to assess the state of the software. I’ve got some examples to show you…
- This is a sample crash alert email. This was sent because the phone I was testing crashed earlier this year. It went to the crash analysis team who contacted me asking for more information. The mail gives the cause of the crash, as a coded set of numbers. This is important because a reboot just looks like a reboot but could be for any number of reasons. It is very easy for human testers to all agree they’ve suffered from the same crash (“Yeah I had that too!”) which can send us chasing our tails. Being able to cluster errors using data prevents this. You can also see whose phone crashed, when and what software version they were using.
- This is a sample crash alert email. This was sent because the phone I was testing crashed earlier this year. It went to the crash analysis team who contacted me asking for more information. The mail gives the cause of the crash, as a coded set of numbers. This is important because a reboot just looks like a reboot but could be for any number of reasons. It is very easy for human testers to all agree they’ve suffered from the same crash (“Yeah I had that too!”) which can send us chasing our tails. Being able to cluster errors using data prevents this. You can also see whose phone crashed, when and what software version they were using.
- This is a sample crash alert email. This was sent because the phone I was testing crashed earlier this year. It went to the crash analysis team who contacted me asking for more information. The mail gives the cause of the crash, as a coded set of numbers. This is important because a reboot just looks like a reboot but could be for any number of reasons. It is very easy for human testers to all agree they’ve suffered from the same crash (“Yeah I had that too!”) which can send us chasing our tails. Being able to cluster errors using data prevents this. You can also see whose phone crashed, when and what software version they were using.
- This is a sample crash alert email. This was sent because the phone I was testing crashed earlier this year. It went to the crash analysis team who contacted me asking for more information. The mail gives the cause of the crash, as a coded set of numbers. This is important because a reboot just looks like a reboot but could be for any number of reasons. It is very easy for human testers to all agree they’ve suffered from the same crash (“Yeah I had that too!”) which can send us chasing our tails. Being able to cluster errors using data prevents this. You can also see whose phone crashed, when and what software version they were using.
- This is a sample crash alert email. This was sent because the phone I was testing crashed earlier this year. It went to the crash analysis team who contacted me asking for more information. The mail gives the cause of the crash, as a coded set of numbers. This is important because a reboot just looks like a reboot but could be for any number of reasons. It is very easy for human testers to all agree they’ve suffered from the same crash (“Yeah I had that too!”) which can send us chasing our tails. Being able to cluster errors using data prevents this. You can also see whose phone crashed, when and what software version they were using.
- This is one of the key dashboards that we use, and the one at the heart of how Splunk has put us on the path to true data led decision making. Here you can see the stability information for a range of different software versions. For each one you can see the total number of hours it has been tested (not the number of hours since the software was released to testers!) and the total number of crashes (not the total number of crashes we think we’ve seen). This allows us to calculated MTBF and choose when the software is mature enough to launch. On this side of the chart we can look at specific crashes. Seeing which crashes are contributing most to the data allows us to focus our fixing effort on the most critical errors first.
- This is one of the key dashboards that we use, and the one at the heart of how Splunk has put us on the path to true data led decision making. Here you can see the stability information for a range of different software versions. For each one you can see the total number of hours it has been tested (not the number of hours since the software was released to testers!) and the total number of crashes (not the total number of crashes we think we’ve seen). This allows us to calculated MTBF and choose when the software is mature enough to launch. On this side of the chart we can look at specific crashes. Seeing which crashes are contributing most to the data allows us to focus our fixing effort on the most critical errors first.
- This is one of the key dashboards that we use, and the one at the heart of how Splunk has put us on the path to true data led decision making. Here you can see the stability information for a range of different software versions. For each one you can see the total number of hours it has been tested (not the number of hours since the software was released to testers!) and the total number of crashes (not the total number of crashes we think we’ve seen). This allows us to calculated MTBF and choose when the software is mature enough to launch. On this side of the chart we can look at specific crashes. Seeing which crashes are contributing most to the data allows us to focus our fixing effort on the most critical errors first.
- This is one of the key dashboards that we use, and the one at the heart of how Splunk has put us on the path to true data led decision making. Here you can see the stability information for a range of different software versions. For each one you can see the total number of hours it has been tested (not the number of hours since the software was released to testers!) and the total number of crashes (not the total number of crashes we think we’ve seen). This allows us to calculated MTBF and choose when the software is mature enough to launch. On this side of the chart we can look at specific crashes. Seeing which crashes are contributing most to the data allows us to focus our fixing effort on the most critical errors first.
- This is one of our stability dashboards. The project managers can use this to drill into the performance of different software versions over time, make comparisons etc. Tell-tale shapes can show up in these graphs, for instance a memory leak could show up as an initially stable software release, which drops after a few days as phones crash due to low memory.
- This is one of our stability dashboards. The project managers can use this to drill into the performance of different software versions over time, make comparisons etc. Tell-tale shapes can show up in these graphs, for instance a memory leak could show up as an initially stable software release, which drops after a few days as phones crash due to low memory.
- That’s where we are today – where are we heading with our transformation? With the cloud, we plan to expand our use of AWS by learning to use Amazon’s resources in ever smarter ways. We’re going to scale up and scale down our estate in order to both respond to fluctuations in demand, as well as being more cost efficient. Amazon EC2 has a feature called Autoscaling that can help with this. We’re also going to look at data services like RDS and DynamoDB to improve the efficiency and reliability of our services. We’re going to keep climbing the Pyramid. This year we are forging ahead to use technologies like Jenkins, Packer and Consul.io to build a world class continuous delivery system. With data, we are going to continue to improve our use of Splunk: real time searches, improved dashboards, combine more data sources. We’re also implementing a feature to raise JIRA tickets directly from our phones to aid testers.
- That’s where we are today – where are we heading with our transformation? With the cloud, we plan to expand our use of AWS by learning to use Amazon’s resources in ever smarter ways. We’re going to scale up and scale down our estate in order to both respond to fluctuations in demand, as well as being more cost efficient. Amazon EC2 has a feature called Autoscaling that can help with this. We’re also going to look at data services like RDS and DynamoDB to improve the efficiency and reliability of our services. We’re going to keep climbing the Pyramid. This year we are forging ahead to use technologies like Jenkins, Packer and Consul.io to build a world class continuous delivery system. With data, we are going to continue to improve our use of Splunk: real time searches, improved dashboards, combine more data sources. We’re also implementing a feature to raise JIRA tickets directly from our phones to aid testers.
- That’s where we are today – where are we heading with our transformation? With the cloud, we plan to expand our use of AWS by learning to use Amazon’s resources in ever smarter ways. We’re going to scale up and scale down our estate in order to both respond to fluctuations in demand, as well as being more cost efficient. Amazon EC2 has a feature called Autoscaling that can help with this. We’re also going to look at data services like RDS and DynamoDB to improve the efficiency and reliability of our services. We’re going to keep climbing the Pyramid. This year we are forging ahead to use technologies like Jenkins, Packer and Consul.io to build a world class continuous delivery system. With data, we are going to continue to improve our use of Splunk: real time searches, improved dashboards, combine more data sources. We’re also implementing a feature to raise JIRA tickets directly from our phones to aid testers.
- That’s where we are today – where are we heading with our transformation? With the cloud, we plan to expand our use of AWS by learning to use Amazon’s resources in ever smarter ways. We’re going to scale up and scale down our estate in order to both respond to fluctuations in demand, as well as being more cost efficient. Amazon EC2 has a feature called Autoscaling that can help with this. We’re also going to look at data services like RDS and DynamoDB to improve the efficiency and reliability of our services. We’re going to keep climbing the Pyramid. This year we are forging ahead to use technologies like Jenkins, Packer and Consul.io to build a world class continuous delivery system. With data, we are going to continue to improve our use of Splunk: real time searches, improved dashboards, combine more data sources. We’re also implementing a feature to raise JIRA tickets directly from our phones to aid testers.
- That’s where we are today – where are we heading with our transformation? With the cloud, we plan to expand our use of AWS by learning to use Amazon’s resources in ever smarter ways. We’re going to scale up and scale down our estate in order to both respond to fluctuations in demand, as well as being more cost efficient. Amazon EC2 has a feature called Autoscaling that can help with this. We’re also going to look at data services like RDS and DynamoDB to improve the efficiency and reliability of our services. We’re going to keep climbing the Pyramid. This year we are forging ahead to use technologies like Jenkins, Packer and Consul.io to build a world class continuous delivery system. With data, we are going to continue to improve our use of Splunk: real time searches, improved dashboards, combine more data sources. We’re also implementing a feature to raise JIRA tickets directly from our phones to aid testers.